CVE-2025-48538 AI-generated analysis

platform/frameworks/base, services/core PackageManagerService (package hiding)

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 (6 corrections). Verify against the commit before relying on it.

Extends the protected-package check in PackageManagerService's package-hiding path so that, in addition to "android", the SystemUI package (resolved via PackageManagerInternal.getSystemUiServiceComponent()) can no longer be hidden.

Root cause

In services/core/java/com/android/server/pm/PackageManagerService.java, the explicit name check in the hide-package path rejected only packageName "android" ("Cannot hide package: android"). The SystemUI package was not covered by that check. Per the commit message, hiding SystemUI makes the phone impossible to use even when done inside a managed profile (tested with a custom DPC). This is the DoS the bulletin rates High.

How the fix works

• services/core/java/com/android/server/pm/PackageManagerService.java, in the method that emits "Cannot hide package" (the hunk header shows only the class; the enclosing method name is not in the material): the condition `"android".equals(packageName)` is extended with `|| LocalServices.getService(PackageManagerInternal.class).getSystemUiServiceComponent().getPackageName().equals(packageName)`.
• When either matches, the method logs `Slog.w(TAG, "Cannot hide package: " + packageName)` and returns false, so the SystemUI package is not hidden by this path.
• The SystemUI package name is resolved at runtime from the configured SystemUI service component rather than hard-coded, so a renamed SystemUI package is covered as long as getSystemUiServiceComponent() returns it.

Completeness

• Covers: the hide-package path shown in PackageManagerService, for exactly two packages: "android" and the package of getSystemUiServiceComponent().
• Does not cover: any other system package in this same path; only these two names are rejected by this check.
• The material shows only this hide path; whether other state-changing paths (e.g. disabling or suspending packages) have an equivalent SystemUI protection is not visible.
• The check compares against a single SystemUI package (the one returned by getSystemUiServiceComponent()).

Behavior changes

• Requests to hide the SystemUI package now fail: the method returns false, for any caller reaching this check (including a DPC in a managed profile, per the commit message).
• The warning log now includes the actual package name ("Cannot hide package: <name>") instead of the fixed string "Cannot hide package: android".
• When packageName is not "android", the check now looks up PackageManagerInternal via LocalServices.

Per major

• Android 14: same fix: platform/frameworks/base 36348592fd27 in android-security-14.0.0_r22, a single hunk (5 insertions, 3 deletions) in PackageManagerService.java at ~line 5765 (resolved via bug_id). At android-security-14.0.0_r29, 1/3 lines of the patched region are present.
• Android 15: same fix: platform/frameworks/base bd7578b738a0 in android-security-15.0.0_r10, identical diff at ~line 5867. At android-security-15.0.0_r17, 1/3 lines of the patched region are present.
• Android 16: same fix: platform/frameworks/base 4e1be9d5eb9b in android-security-16.0.0_r1, identical diff at ~line 5957. At android-security-16.0.0_r8, 1/3 lines of the patched region are present.
• Android 17: not listed by the bulletin (not affected per the bulletin); at android-security-17.0.0_r1, 2/3 lines of the patched region are present. The actual code there is not in the material.

Unknowns

• The name of the enclosing method is not shown (the hunk header shows only the class).
• The per-major facts report only 1/3 patched-region lines present at the latest 14/15/16 security tags even though the fix is resolved there; whether this is a line-matching artifact or a later rewrite of the region is not shown.
• What the patched region looks like at android-security-17.0.0_r1 (2/3 lines matched) is not shown.
• Whether other package state paths (disable, suspend, uninstall for user) have equivalent SystemUI protection is not visible in the material.
• The exact API/permission used to trigger the hide is not shown beyond the commit message's reference to a custom DPC.

Back to September 2025 · Findings