CVE-2024-0044 AI-generated analysis
platform/frameworks/base, services/core PackageManager / PackageInstallerService (session creation)
PackageInstallerService session creation now rejects (nulls out) app and installer package names that are over-long or contain characters not accepted by FrameworkParsingPackageUtils.validateName, instead of only checking their length.
Root cause
In services/core/java/com/android/server/pm/PackageInstallerService.java, the session-creation path set params.appPackageName to null only if it was longer than SessionParams.MAX_PACKAGE_NAME_LENGTH, and used params.installerPackageName as requestedInstallerPackageName only if it was shorter than that limit. The separate installerPackageName argument was not validated at all. The surrounding comment says package name and label length are restricted so that really long strings aren't written to disk, but nothing checked that these strings were syntactically valid package names, so arbitrary character content could flow into the installer/app package name used by the session.
How the fix works
- Commit 954b2874b85b (android-security-14.0.0_r6), PackageInstallerService.java: adds a private static isValidPackageName(String) that returns false if the name exceeds SessionParams.MAX_PACKAGE_NAME_LENGTH or if FrameworkParsingPackageUtils.validateName(packageName, requireSeparator=false, requireFilename=true) returns an error message; imports android.content.pm.parsing.FrameworkParsingPackageUtils.
- Same commit, session-creation path: replaces the length-only check on params.appPackageName with isValidPackageName (invalid -> null); adds an explicit check that nulls params.installerPackageName when invalid; requestedInstallerPackageName becomes params.installerPackageName if non-null else the installerPackageName argument.
- Commit 836750619a8b (android-security-14.0.0_r13), same method: adds a second check that nulls the installerPackageName method argument when it fails isValidPackageName, so the fallback value used for requestedInstallerPackageName (and passed later to mAppOps.checkPackage for non-system callers) is also validated; changes 'var' to 'String' for requestedInstallerPackageName (no semantic effect).
Completeness
- From the code: all three package-name inputs visible in this method are now validated with the same helper: params.appPackageName, params.installerPackageName, and the installerPackageName argument.
- The validation is applied only at session creation in PackageInstallerService; the material does not show whether other paths that record or change installer names are validated, so coverage of those is unknown.
- params.appLabel is only trimmed to PackageItemInfo.MAX_SAFE_LABEL_LENGTH (unchanged); no character validation is applied to it, which is consistent with it being a label rather than a package name.
- Invalid values are silently replaced by null rather than rejected with an error, so a caller does not get feedback that its name was dropped.
Behavior changes
- Package names containing characters rejected by FrameworkParsingPackageUtils.validateName (requireSeparator=false, requireFilename=true) are now treated as absent (null) for appPackageName, params.installerPackageName and the installerPackageName argument; the bare name 'android' remains accepted per the in-code comment.
- params.installerPackageName is now mutated to null when invalid (previously it was left untouched and only skipped as the requested installer when too long).
- For non-root/shell/system callers an invalid installerPackageName argument is now null when mAppOps.checkPackage(callingUid, installerPackageName) runs; the resulting behavior of that call is not shown in the material.
Per major
- Android 14: Resolved via two commits on the android-security-14.0.0 branch: 954b2874b85b (r6, adds isValidPackageName and validates params.appPackageName/params.installerPackageName) and 836750619a8b (r13, validates the installerPackageName argument). Patched region present at android-security-14.0.0_r29 (7/8 lines).
- Android 15: Not affected (not listed by the bulletin); 7/8 lines of the patched region are present at android-security-15.0.0_r17.
- Android 16: Not affected (not listed by the bulletin); 7/8 lines of the patched region are present at android-security-16.0.0_r8.
- Android 17: Not affected (not listed by the bulletin); 7/8 lines of the patched region are present at android-security-17.0.0_r1.
Unknowns
- The exact consequence of an invalid installer/app package name being accepted (what downstream consumer of the name was affected) is not shown in the material.
- The enclosing method name is not shown in the diff header beyond the class; the code is the session-creation path using SessionParams, installerPackageName and callingUid.
- Behavior of mAppOps.checkPackage when installerPackageName has been nulled by the new check is not shown.
- Whether the 12, 12L and 13 branches received the same two-commit sequence is not shown in the material.
- Why only 7/8 lines of the patched region match at the latest tags, and how the code reached 15-17, is not shown.