CVE-2025-32321 AI-generated analysis
platform/packages/apps/Settings, accounts (AccountTypePreferenceLoader)
In Settings' AccountTypePreferenceLoader.isSafeIntent, the fix keeps the existing check that the activity an intent resolves to belongs to the authenticator's uid. When the check passes, it now pins the intent to that resolved component with intent.setComponent(), so the intent becomes explicit and targets the validated activity.
Root cause
isSafeIntent(PackageManager, Intent, String accountType) resolves the intent with pm.resolveActivityAsUser(intent, 0, user). It returns true when the resolved activity's applicationInfo.uid equals the uid of the authenticator package. It returned only a boolean and left the Intent unchanged, so an intent that passed the check stayed implicit. The commit message says the change prevents arbitrary intents from being launched from Settings.
How the fix works
- src/com/android/settings/accounts/AccountTypePreferenceLoader.java:isSafeIntent: the line `return resolvedAppInfo.uid == authenticatorAppInf.uid;` is replaced by an if/else. When the uids match, the method calls intent.setComponent(resolvedActivityInfo.getComponentName()) and then returns true, which makes the intent explicit and points it at the resolved, authenticator-owned activity. Otherwise it returns false.
- The existing checks are unchanged: content-scheme intents are rejected, a null result from resolveActivityAsUser is rejected, and a NameNotFoundException for the authenticator package is logged and rejected.
- Single commit touching one file, with the same hunk content on 14, 15 and 16 (Change-Id I0e67f1258cb427c5b998e40a8a0c104af3ead042).
Completeness
- Covers the uid-match path: any intent that passes isSafeIntent is now explicit and bound to the component that was validated.
- The fix assumes the caller launches the same Intent object it passed to isSafeIntent. The caller is not in the material, so the diff cannot confirm this.
- Only the authenticator-uid branch changes. The allowedFragments handling shown above the function is untouched.
- Resolution still uses flags 0 with resolveActivityAsUser. The fix does not change which activity is picked; it only pins the picked one.
Behavior changes
- isSafeIntent now changes its Intent argument: on success, the intent gets an explicit ComponentName (the resolved authenticator activity).
- Intents that pass the check now target the specific resolved activity instead of staying implicit.
- No new error codes, logs or rejections. Intents that were rejected before are still rejected.
Per major
- Android 14: same fix: commit fd19bf11ef08 in android-security-14.0.0_r22. The check finds 4/5 lines of the patched region at android-security-14.0.0_r29, and the code context there shows the setComponent fix.
- Android 15: same fix: commit bb6e84fd04fc in android-security-15.0.0_r10, same hunk content. The check finds 4/5 lines of the patched region at android-security-15.0.0_r17.
- Android 16: same fix: commit e985e294f15d in android-security-16.0.0_r1, same hunk content. The check finds 4/5 lines of the patched region at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin). The check finds 4/5 lines of the patched region at android-security-17.0.0_r1.
Unknowns
- The caller of isSafeIntent and how the Intent is launched afterwards.
- The exact way an implicit intent could end up launching an activity that was not validated. The commit message only mentions arbitrary intents and activities.
- The user flow that reaches this code (for example, which Settings screen loads the authenticator's preferences).
- Whether and how the fix was applied to Android 13, which the bulletin lists as affected.