CVE-2024-0025 AI-generated analysis
platform/frameworks/base, services/core ActivityManagerService (PendingIntent / IIntentSender dispatch)
ActivityManagerService.sendIntentSender no longer forwards the caller-supplied allowlistToken to a target IIntentSender that is not a PendingIntentRecord; it passes null instead and logs a Slog.wtf when a non-null token was supplied on that path.
Root cause
In ActivityManagerService.sendIntentSender, when the target IIntentSender is not a PendingIntentRecord (the else branch, which the code comment describes as "someone has given us their own custom IIntentSender ... this isn't really a PendingIntent"), the code called target.send(code, intent, resolvedType, allowlistToken, null, requiredPermission, options) and passed the allowlistToken argument unchanged to the custom target. The code comment in the same branch notes that such an intent sender may come from outside the system, so the token could reach a party outside the system.
How the fix works
- services/core/java/com/android/server/am/ActivityManagerService.java:sendIntentSender (non-PendingIntent else branch): the target.send(...) call now passes null in place of allowlistToken, so a custom IIntentSender never receives the token.
- Same location: if allowlistToken != null, the fix resolves the calling package via AppGlobals.getPackageManager().getNameForUid(Binder.getCallingUid()) under Binder.clearCallingIdentity()/restoreCallingIdentity(), then emits Slog.wtf(TAG, "Send a non-null allowlistToken to a non-PI target...") with the calling package, intent and options. The commit message says this logging is meant to detect whether real callers hit this case.
- The commit message combines two descriptions ("Log to detect usage of whitelistToken when sending non-PI target" and "Do not pass whitelistToken when sending non-PI target"). In the provided diff both are in a single RESTRICT AUTOMERGE cherry-pick (Change-Id I017486354a1ab2f14d0472c355583d53c27c4810).
Completeness
- Covers only the non-PendingIntentRecord branch of sendIntentSender. The PendingIntentRecord branch (sendWithResult, for both originalRecord and the visible-background-user redirected newRecord) still passes allowlistToken on.
- The token is dropped no matter who the caller is. On this path there is no check or exception for system callers.
- The later finishedReceiver.performReceive(...) call in the same branch is unchanged.
- The Slog.wtf is diagnostic only; it does not reject the send.
Behavior changes
- Custom (non-PendingIntent) IIntentSender targets now always receive a null allowlistToken from sendIntentSender.
- A Slog.wtf is logged whenever a non-null allowlistToken is passed to a non-PI target. This adds an IPackageManager.getNameForUid lookup performed with cleared calling identity. Slog.wtf produces a wtf report, typically recorded in DropBox (general platform knowledge).
Per major
- Android 14: same fix: commit 2c3fb40bca62 in android-security-14.0.0_r4 (RESTRICT AUTOMERGE cherry-pick). At android-security-14.0.0_r29, 3/4 lines of the patched region are present, and the code shown there contains the null-token call and the wtf log.
- Android 15: not affected per the bulletin. At android-security-15.0.0_r17, 3/4 lines of the patched region are present (code not shown).
- Android 16: not affected per the bulletin. At android-security-16.0.0_r8, 3/4 lines of the patched region are present (code not shown).
- Android 17: not affected per the bulletin. At android-security-17.0.0_r1, 3/4 lines of the patched region are present (code not shown).
Unknowns
- How a recipient of the allowlistToken could use it; the material does not show the consumer side of the token.
- Which client-facing APIs reach sendIntentSender with a non-null allowlistToken and a custom IIntentSender.
- Whether the one unmatched line in later tags is only a formatting difference in the log statement or a further change.
- The exact content of the patched region in the 15, 16 and 17 tags.