CVE-2025-0091 AI-generated analysis

platform/packages/apps/Settings, accounts (AccountTypePreferenceLoader)

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

Settings' AccountTypePreferenceLoader.isSafeIntent now returns false for any authenticator-supplied preference Intent whose scheme is "content", so it is not treated as safe to launch.

Root cause

AccountTypePreferenceLoader handles preference Intents contributed by account authenticators and launches them from Settings for the user (prefIntent, mUserHandle) unless isSafeIntent rejects them, in which case it logs "Refusing to launch authenticator intent because it exploits Settings permissions". Per its doc comment, isSafeIntent only checked that the Intent launches an exported activity or one owned by the same uid as the authenticator; it did not consider the Intent's URI scheme, so an Intent with a content scheme could be launched with Settings' permissions. The bulletin rates this High EoP.

How the fix works

• src/com/android/settings/accounts/AccountTypePreferenceLoader.java:isSafeIntent: adds an early check `TextUtils.equals(intent.getScheme(), ContentResolver.SCHEME_CONTENT)`; if true, logs "Intent with a content scheme is unsafe." and returns false, before the existing resolveActivityAsUser / exported / same-uid checks.
• Same file: isSafeIntent changed from private to package-private with @VisibleForTesting; parameter renamed acccountType -> accountType; imports android.content.ContentResolver; whitespace fix in the refuse-to-launch log message (cosmetic).
• tests/robotests/.../AccountTypePreferenceLoaderTest.java: new test isSafeIntent_hasContextScheme_returnFalse builds an Intent with ClipData containing a content://com.android.settings.files/... URI and asserts isSafeIntent returns false.

Completeness

• Covers: Intents whose scheme is exactly "content", as returned by intent.getScheme(), are rejected by isSafeIntent.
• The new check inspects only intent.getScheme(), which reflects the data URI (Intent.getScheme semantics are general platform knowledge); content URIs carried only in ClipData are not examined by this check. The added test sets only ClipData and no data URI.
• Other schemes and the existing exported/same-uid logic are unchanged; no change to the launch call itself.

Behavior changes

• Authenticator preference Intents with a content scheme are rejected by isSafeIntent with Log.e "Intent with a content scheme is unsafe."; the click handler then logs the refuse-to-launch message and returns true.
• isSafeIntent becomes package-visible (@VisibleForTesting).

Per major

• Android 14: same fix: commit 35d9352cf9d6 in android-security-14.0.0_r17 (cherry-pick of 841fb3846b25); at android-security-14.0.0_r29, 7/8 lines of the patched region present.
• Android 15: same fix: commit e3bbc415adb5 in android-security-15.0.0_r5, same source change; test diff differs in context and does not add the assertThat import; at android-security-15.0.0_r17, 7/8 lines of the patched region present.
• Android 16: not affected (not listed by the bulletin); at android-security-16.0.0_r8, 7/8 lines of the patched region present.
• Android 17: not affected (not listed by the bulletin); at android-security-17.0.0_r1, 7/8 lines of the patched region present.

Unknowns

• Fix commits for Android 12, 12L and 13 (listed as affected) are not in the material.
• Whether other code in AccountTypePreferenceLoader inspects ClipData or URI grant flags is not shown.
• How the new test's false result arises (new branch vs. existing resolve path) depends on mock setup not shown.
• The 1/8 line difference between the fix and the latest security tags is not shown.
• The exact launch call and which component owns the content://com.android.settings.files authority are not shown.

Back to February 2025 · Findings