CVE-2026-28614 AI-generated analysis

platform/frameworks/base, SystemUI (packages/SystemUI/src/com/android/systemui/SlicePermissionActivity.java), slice permission request dialog

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

Adds a caller check to SystemUI's SlicePermissionActivity.onCreate so the slice permission dialog is only shown when the activity was actually launched by the slice provider's package, SystemUI itself, or the "android" package; any other launcher is finished immediately.

Root cause

SlicePermissionActivity.onCreate reads mUri from SliceProvider.EXTRA_BIND_URI and mCallingPkg from SliceProvider.EXTRA_PKG, both taken directly from the incoming Intent. The only validation was that the URI type is SLICE_TYPE, the action is ACTION_REQUEST_SLICE_PERMISSION, and that verifyCallingPkg() compared an optional "provider_pkg" extra against the resolved provider package. Nothing checked which application actually started the activity, so the package named in EXTRA_PKG (used as the requesting app label in the dialog) was fully controlled by whoever launched the activity. Per the commit message, this let a malicious app trick the user into granting slice permissions by spoofing the package name in the intent (a confused deputy in SystemUI).

How the fix works

• SlicePermissionActivity.java:onCreate: after mProviderPkg is resolved and verifyCallingPkg() runs, and before any dialog UI is built, a new check `if (!isCallerValid()) { finish(); return; }` stops the activity for untrusted launchers.
• SlicePermissionActivity.java:isCallerValid (new): finds the real launcher with getLaunchedFromPackage(), falling back to getCallingPackage() when that is null. It returns true only if the launcher is non-null and equals mProviderPkg (the package owning the slice authority), equals getPackageName() (SystemUI itself), or equals the literal "android". Otherwise it logs "Direct launch blocked. Expected provider ... or system, but got ..." at error level and returns false.
• SlicePermissionActivityTest.kt (new): unit tests covering valid launchers (provider package, com.android.systemui, android, and fallback to getCallingPackage) and an invalid launcher (SPOOF_PKG) asserting that finish() is invoked.

Completeness

• The check gates the only entry point shown (onCreate) and sits before the dialog is created, so the user is never prompted for launches from untrusted packages.
• Only the launcher identity is validated. EXTRA_PKG itself is still taken from the intent and not cross-checked against the launcher, so a trusted launcher can still name any package.
• The allowlist is by package name string (mProviderPkg, SystemUI's own package name, "android"), not by UID or signature.
• If both getLaunchedFromPackage() and getCallingPackage() return null, the activity is blocked (fail closed).
• The existing verifyCallingPkg() logic for the "provider_pkg" extra is unchanged; the new check is added on top of it.
• The onClick/grant path and the AndroidManifest exported state of the activity are not in the diff and are unchanged by it.

Behavior changes

• Launches of SlicePermissionActivity from any package other than the slice provider's package, SystemUI, or "android" now finish immediately without showing the permission dialog.
• A new Log.e line "Direct launch blocked. Expected provider <pkg> or system, but got <caller>" is emitted for blocked launches.
• Requests launched by the slice provider's own package still pass the check.
• New test file SlicePermissionActivityTest.kt added to the SystemUI test suite.

Per major

• Android 14: same fix: commit c6b5038a9e23 in android-security-14.0.0_r29 (cherry-pick of 7f44449562bc, Change-Id I49822e9f7eb2d29278d1266ae2fd51fc154744db); identical code change at different line offsets (hunks @@ -66 / -110); 8/8 patched lines present.
• Android 15: same fix: commit 971f1d196295 in android-security-15.0.0_r17; hunks @@ -72 / -116 and the same new test file; 8/8 patched lines present.
• Android 16: same fix: commit dba6ec2c05ff in android-security-16.0.0_r8; identical hunks and test file as 15; 8/8 patched lines present.
• Android 17: same fix: commit 7e25b93a1faa in android-security-17.0.0_r1; identical hunks and test file as 15/16; 8/8 patched lines present.

Unknowns

• The onClick handler that actually grants slice access is not in the material, so the exact privilege granted on user acceptance is not shown.
• The AndroidManifest declaration (exported state, intent filter, permissions) of SlicePermissionActivity is not shown.
• The catch block following the try in onCreate is not shown, so behaviour when resolveContentProvider returns null is unknown.

Back to September 2026 · Findings