CVE-2025-48545 AI-generated analysis

platform/frameworks/base, AccountManagerService (services/core/java/com/android/server/accounts)

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

AccountManagerService.isSystemUid() now returns false immediately for SDK sandbox UIDs instead of deriving system status from the packages that PackageManager associates with that UID.

Root cause

AccountManagerService.isSystemUid(int callingUid) decides whether a caller is "system" by calling mPackageManager.getPackagesForUid(callingUid) and returning true if any returned package has ApplicationInfo.FLAG_SYSTEM. It did not exclude SDK sandbox UIDs. A sandbox caller could therefore be classified as system if PackageManager returned a system-flagged package for its UID, and then pass checks in AccountManagerService that rely on isSystemUid(). The material does not show which package is returned for a sandbox UID. The bulletin rates this as High severity information disclosure.

How the fix works

• services/core/java/com/android/server/accounts/AccountManagerService.java:isSystemUid(): adds an early `if (Process.isSdkSandboxUid(callingUid)) return false;` before the package lookup. SDK sandbox callers are therefore never classified as system, whichever packages PackageManager reports for that UID.
• The rest of the method is unchanged: clearCallingIdentity, getPackagesForUid, the FLAG_SYSTEM loop and restoreCallingIdentity. Only the sandbox case is short-circuited.

Completeness

• The fix covers every caller of isSystemUid() in AccountManagerService, because the check is inside the helper itself.
• It only addresses the SDK sandbox UID case. The underlying approach of inferring system status from FLAG_SYSTEM on any package sharing the UID is otherwise unchanged.
• Other privilege checks in the file that do not go through isSystemUid() are not touched by this commit. One example is the direct `UserHandle.getAppId(callerUid) == Process.SYSTEM_UID` comparison at line 5969 of the surrounding context. The material does not show whether those checks needed changes.
• The material does not show which AccountManagerService entry points call isSystemUid(), and the index search returned no caller chunks. The exact set of protected operations therefore cannot be listed here.

Behavior changes

• isSystemUid() now treats callers running in an SDK sandbox process as non-system. Any AccountManagerService operation gated on that helper will take the non-system path for sandbox callers.
• No new error codes, logging or API changes, and no behavior change for non-sandbox UIDs.

Per major

• Android 14: same fix: commit 30dc386d4a57 in android-security-14.0.0_r22, a 3-line early return in isSystemUid(). 3/3 lines are present at android-security-14.0.0_r29.
• Android 15: same fix: commit 66ac17909252 in android-security-15.0.0_r10, identical hunk at a different line offset (6080). 3/3 lines are present at android-security-15.0.0_r17.
• Android 16: same fix: commit c21f79312d3f in android-security-16.0.0_r1, identical hunk at line offset 6146. 3/3 lines are present at android-security-16.0.0_r8.
• Android 17: not affected per the bulletin. The 3 patched lines are already present at android-security-17.0.0_r1.

Unknowns

• Which AccountManagerService methods call isSystemUid(), and therefore what account data or operations were exposed.
• Which packages PackageManager.getPackagesForUid() returns for an SDK sandbox UID, and so exactly how a sandbox caller was classified as system before the fix.
• Whether an Android 13 fix commit exists (the bulletin lists 13 as affected, but no 13 commit is in the material).
• The original bug report details (Bug 397438392) and any accompanying test changes.

Back to September 2025 · Findings