CVE-2024-0046 AI-generated analysis

platform/frameworks/base, PackageManagerService / InstallPackageHelper (install existing package as user)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (2 corrections). Verify against the commit before relying on it.

Adds a check in the install-existing-package path of InstallPackageHelper so that a request carrying INSTALL_INSTANT_APP is rejected with INSTALL_FAILED_INVALID_URI when the target package is a system app or an updated system app.

Root cause

In services/core/java/com/android/server/pm/InstallPackageHelper.java, the method that installs an already-present package for a user (the one whose cross-user check is labelled "installExistingPackage for user") computed `instantApp` from the INSTALL_INSTANT_APP install flag. After confirming the PackageSetting existed, it went on to install the package for the user without checking whether it was a system or updated-system package. The only instant-app related gate was `snapshot.canViewInstantApps(...)`, which is about whether the caller can see instant apps, not about what kind of package the target is. So a caller that passed the INSTALL_PACKAGES / INSTALL_EXISTING_PACKAGES permission check could have a system app installed for a user as an instant app. The commit title says this should be disallowed.

How the fix works

• InstallPackageHelper.java (install-existing path, inside `synchronized (mPm.mLock)` right after the `pkgSetting == null || pkgSetting.getPkg() == null` check): adds `if (instantApp && (pkgSetting.isSystem() || pkgSetting.isUpdatedSystemApp())) return Pair.create(PackageManager.INSTALL_FAILED_INVALID_URI, intentSender);`. This rejects the request before the canViewInstantApps check and before any state change (setInstalled / setHidden / writePackageRestrictionsLPr).
• The check runs under mPm.mLock against the PackageSetting just read from mPm.mSettings.
• At android-security-14.0.0_r29 the same condition is extended with `|| isPackageDeviceAdmin || isProtectedPackage` (local booleans computed before the lock from mPm.isPackageDeviceAdmin and mPm.mProtectedPackages.isPackageStateProtected). That extension is not part of commit 022aff702e66; it comes from a later change that the material does not include.

Completeness

• The fix covers only the install-existing path in InstallPackageHelper.java. It rejects instant installs when the PackageSetting is system or updated-system.
• The commit itself does not cover device-admin or protected packages. The r29 tree shows those were added to the same condition later.
• The regular APK install path (a new install session with INSTALL_INSTANT_APP) is not touched by this commit. The material does not show whether an equivalent check exists there, so no conclusion is drawn.
• The check uses the PackageSetting flags, not per-user state. It does not depend on whether the user already has the package installed.

Behavior changes

• Install-existing requests with INSTALL_INSTANT_APP that target a system or updated-system package now fail with PackageManager.INSTALL_FAILED_INVALID_URI (a code this method already returns for other rejections) instead of succeeding.
• No change for non-instant (full app) install-existing requests or for non-system packages.

Per major

• Android 14: same fix: commit 022aff702e66 in android-security-14.0.0_r6 (Change-Id Idd89a6dd72f0e68259095f677185f0494391025c). At android-security-14.0.0_r29 the patched region is present (5/5 lines), and the condition has been extended with isPackageDeviceAdmin || isProtectedPackage by a later change.
• Android 15: not affected per the bulletin; the patched region is present (5/5 lines) at android-security-15.0.0_r17.
• Android 16: not affected per the bulletin; the patched region is present (5/5 lines) at android-security-16.0.0_r8.
• Android 17: not affected per the bulletin; the patched region is present (5/5 lines) at android-security-17.0.0_r1.

Unknowns

• The enclosing method signature is not shown in the context. The method is identified only by its "installExistingPackage for user" cross-user permission label.
• The concrete security impact of a system app being marked instant for a user is not described in the material beyond the commit title and the bulletin's EoP/High rating.
• The bulletin lists 12, 12L and 13 as affected, but the material does not include the fixes or the code location for those branches.
• The later commit that added isPackageDeviceAdmin/isProtectedPackage to the condition is not identified in the material.
• Whether the extended condition is present on 15, 16 and 17 is not shown; only the 5/5 line presence of the patched region is reported.

Back to March 2024 · Findings