CVE-2025-0086 AI-generated analysis
platform/frameworks/base, services/core AccountManagerService (accounts)
Adds a check in AccountManagerService's getAuthToken result handler that rejects an authenticator response whose KEY_ACCOUNT_TYPE differs from the session's account type, returning ERROR_CODE_INVALID_RESPONSE instead of storing the token.
Root cause
In AccountManagerService.java, the getAuthToken Session's onResult(Bundle result) built an Account from the KEY_ACCOUNT_NAME and KEY_ACCOUNT_TYPE strings returned by the AbstractAccountAuthenticator. When customTokens was false, it passed that resultAccount to saveAuthTokenToDatabase. The only validation was that name and type were non-empty. The commit message says the service already knows which account getAuthToken is called for, but the code did not check that the returned type matched the session's mAccountType. As a result, the authenticator could have an auth token recorded under an account of a different type.
How the fix works
- services/core/java/com/android/server/accounts/AccountManagerService.java, getAuthToken Session.onResult: after the existing TextUtils.isEmpty(type) || TextUtils.isEmpty(name) check and before `Account resultAccount = new Account(name, type)`, the fix adds `if (!type.equals(mAccountType)) { onError(AccountManager.ERROR_CODE_INVALID_RESPONSE, "incorrect account type"); return; }`.
- The check comes before both the `!customTokens` saveAuthTokenToDatabase(mAccounts, resultAccount, ...) call and the customTokens saveCachedToken path. A mismatched type therefore ends result handling and nothing is persisted or cached.
- Single commit, 6 added lines, no other files touched. The commit message says the response keys look unnecessary but the API cannot change at this moment, so a validation check was added.
Completeness
- Covers only the getAuthToken Session.onResult path in AccountManagerService. The type returned by the authenticator is compared to mAccountType.
- KEY_ACCOUNT_NAME returned by the authenticator is still accepted as-is. The fix does not compare `name` to the requested account's name, so resultAccount can still carry a name chosen by the authenticator, as long as the type is correct.
- Other authenticator callbacks that also return KEY_ACCOUNT_NAME/KEY_ACCOUNT_TYPE are not part of this diff. The material does not show whether they already validate the type.
- The customTokens branch passes the original `account` to saveCachedToken, so it did not rely on the authenticator-supplied type. The new check still gates that branch.
Behavior changes
- A getAuthToken response whose KEY_ACCOUNT_TYPE does not equal the session's account type now fails with AccountManager.ERROR_CODE_INVALID_RESPONSE and the message "incorrect account type" instead of succeeding.
- In that case no token is written to the database or cached.
Per major
- Android 14: same fix: platform/frameworks/base b6dcda18039c in android-security-14.0.0_r18 (cherry-picked from ab3a6b9e5ced, Change-Id Ifc62866f4feaca43abc32bc542b97f3741953f56). All 4 lines of the patched region are present at android-security-14.0.0_r29 (hunk at about line 3124, context now at line 3217).
- Android 15: same fix: platform/frameworks/base c1aa9e662464 in android-security-15.0.0_r6, with an identical 6-line hunk at about line 3190. All 4 lines are present at android-security-15.0.0_r17.
- Android 16: not affected (not listed by the bulletin). All 4 lines of the patched region are present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin). All 4 lines of the patched region are present at android-security-17.0.0_r1.
Unknowns
- The material does not show the fix commits for Android 12, 12L and 13, which the bulletin lists as affected.
- The material does not show what concrete information disclosure results from a token stored under the wrong account type. The bulletin only rates it High / ID.
- No automated test is shown with the change (Test: manual).