CVE-2026-28603 AI-generated analysis

platform/packages/apps/Settings, users / AppRestrictionsFragment (app restrictions custom activity launch)

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.

In Settings' AppRestrictionsFragment, the vetted copy of the app-supplied custom restrictions activity Intent now has all four FLAG_GRANT_*_URI_PERMISSION flags removed and its data and clipData cleared before Settings calls startActivityForResult on it.

Root cause

RestrictionsResultReceiver.assertSafeToStartCustomActivity in src/com/android/settings/users/AppRestrictionsFragment.java builds vettedIntent as new Intent(intent) from the untrusted Intent, resolves it, checks only that the resolved activity's package equals the expected packageName, then pins component and package. Everything else from the untrusted Intent was kept, including FLAG_GRANT_READ/WRITE/PERSISTABLE/PREFIX_URI_PERMISSION, the data URI and the ClipData. The caller (lines 658-661) then invokes AppRestrictionsFragment.this.startActivityForResult(vettedIntent, requestCode), so Settings launched the activity with grant flags and URIs chosen by the app.

How the fix works

• src/com/android/settings/users/AppRestrictionsFragment.java : RestrictionsResultReceiver.assertSafeToStartCustomActivity: after setComponent/setPackage, calls vettedIntent.removeFlags(FLAG_GRANT_READ_URI_PERMISSION | FLAG_GRANT_WRITE_URI_PERMISSION | FLAG_GRANT_PERSISTABLE_URI_PERMISSION | FLAG_GRANT_PREFIX_URI_PERMISSION).
• Same function: vettedIntent.setData(null) and vettedIntent.setClipData(null) clear the data URI and ClipData. The returned vettedIntent is what the existing caller passes to startActivityForResult.
• tests/robotests/src/com/android/settings/users/AppRestrictionsFragmentTest.java (new): assertSafeToStartCustomActivity_stripsSensitiveData calls the private method through ReflectionHelpers with a mocked PackageManager. It asserts that all four grant flags are clear and that data and clipData are null.

Completeness

• Covers the path that launches the app-supplied custom restrictions activity: all four URI grant flags, data and clipData are stripped from the vetted copy.
• Only Intent flags, data and clipData are touched. The Intent's extras, action, categories, type and other flags are still forwarded unchanged from the untrusted Intent (the diff does not address them).
• The existing package-equality check on the resolved activity is unchanged. The fix adds sanitization on top of it and does not change the vetting.
• The new test only exercises the stripping behaviour. No test covers the end-to-end receiver flow.

Behavior changes

• Custom restrictions activities launched by AppRestrictionsFragment no longer receive the data URI or ClipData that the app placed on its Intent, and the four URI grant flags are removed.
• No new exception or error path: the Intent is sanitized silently.

Per major

• Android 14: same fix: 0f9f6238cf25 in android-security-14.0.0_r29, identical hunk at line 687 plus new robolectric test; 4/4 patched lines present.
• Android 15: same fix: 856f8ccca12e in android-security-15.0.0_r17, identical hunk at line 683; 4/4 patched lines present.
• Android 16: same fix: 3bf7abe6e14b in android-security-16.0.0_r8, identical hunk at line 683 (same file blob as 15); 4/4 patched lines present.
• Android 17: same fix: a3cbe8fbf286 in android-security-17.0.0_r1, identical hunk at line 726; 4/4 patched lines present.

Unknowns

• The material does not show how RestrictionsResultReceiver obtains the custom activity Intent (the broadcast/result extras path).
• The material does not show which content providers or URI permissions the bulletin considers exposed.
• Whether URIs carried in the forwarded extras could still lead to grants is not shown by the material.
• Whether the two internal Cherrypick-From commits differ from each other is not shown.

Back to September 2026 · Findings