CVE-2025-48633 AI-generated analysis

platform/frameworks/base, DevicePolicyManagerService (services/devicepolicy)

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

DevicePolicyManagerService.hasAccountsOnAnyUser() is changed to query AccountManagerService.getSingleton().getAllAccountsForSystemProcess() instead of iterating users and calling AccountManager.getAccounts(). Per the commit title, this makes it count all accounts regardless of visibility.

Root cause

hasAccountsOnAnyUser() cleared the calling identity, looped over mUserManagerInternal.getUsers(excludeDying=true), created a per-user context and called AccountManager.getAccounts(). The commit title ("Get all accounts no matter the visibility") indicates that this enumeration was affected by account visibility, so some existing accounts could be missed. The helper could then report no accounts while accounts existed. The material does not show which decision depends on this helper.

How the fix works

• services/devicepolicy/java/com/android/server/devicepolicy/DevicePolicyManagerService.java:hasAccountsOnAnyUser(): the user loop, the per-user AccountManager contexts and Binder.clearCallingIdentity()/restoreCallingIdentity() are removed.
• The method now obtains the in-process AccountManagerService via AccountManagerService.getSingleton() and returns getAllAccountsForSystemProcess().length != 0. Per the method name and commit title, this is an account list for the system process that is not filtered by visibility.
• A new import com.android.server.accounts.AccountManagerService is added.

Completeness

• Only hasAccountsOnAnyUser() is changed. All callers of this private helper get the corrected result.
• Whether getAllAccountsForSystemProcess() covers all users and whether it includes dying users (previously excluded via excludeDying=true) is not shown in the material.
• No other AccountManager uses in DevicePolicyManagerService are touched by this commit. The material does not show whether other similar presence checks exist.

Behavior changes

• hasAccountsOnAnyUser() can now return true in cases where the previous visibility-filtered enumeration returned no accounts.
• The helper no longer clears and restores the Binder calling identity and no longer creates per-user contexts. It uses the AccountManagerService singleton directly inside system_server.
• The helper now depends on AccountManagerService.getSingleton() being available when it runs.

Per major

• Android 14: same fix: platform/frameworks/base 527b25ca541f in android-security-14.0.0_r24 (cherry-pick of a8819d3bdc49); 8/8 lines present at android-security-14.0.0_r29
• Android 15: same fix: platform/frameworks/base e74b3376e899 in android-security-15.0.0_r12, identical diff; 8/8 lines present at android-security-15.0.0_r17
• Android 16: same fix: platform/frameworks/base d00bcda9f42d in android-security-16.0.0_r3, identical diff; 8/8 lines present at android-security-16.0.0_r8
• Android 17: not affected (not listed by the bulletin); patched code (8/8 lines) already present at android-security-17.0.0_r1

Unknowns

• Which DevicePolicyManagerService path calls hasAccountsOnAnyUser() and what decision it gates (neither the material nor the index shows the caller).
• Exact semantics of getAllAccountsForSystemProcess() (user coverage, handling of dying users).
• Exact visibility behavior of AccountManager.getAccounts() in the old code path, beyond what the commit title implies.
• The Android 13 fix commit is not included in the material.

Back to December 2025 · Findings