CVE-2025-26426 AI-generated analysis
platform/frameworks/base, ActivityManagerService (broadcast receiver registration)
Removes the special case in ActivityManagerService.registerReceiverWithFeature that let any caller pass "android" as callerPackage without being validated against the calling process's package list, and then widens the exemption from SYSTEM_UID to all core uids so system components in other core processes keep working.
Root cause
In services/core/java/com/android/server/am/ActivityManagerService.java, registerReceiverWithFeature verified that the supplied callerPackage is actually running in the calling process (callerApp.getPkgList().containsKey(callerPackage)) unless the caller was SYSTEM_UID, but it also skipped the check whenever callerPackage equaled "android" (`&& !"android".equals(callerPackage)`). A caller with a process record known to AMS could therefore supply "android" as its package name without the ownership check; in the shown context callerPackage is then passed to isInstantApp and mUserController.handleIncomingUser.
How the fix works
- Commit d48f297f2165 (first): ActivityManagerService.java:registerReceiverWithFeature drops the `&& !"android".equals(callerPackage)` clause, so a non-SYSTEM_UID caller whose process does not contain callerPackage now hits the SecurityException("Given caller package ... is not running in process ...") regardless of the name supplied.
- Commit 93c036bb67be (second, same hunk): replaces `callerApp.info.uid != SYSTEM_UID` with `!UserHandle.isCore(callerApp.info.uid)`. Per the commit message, system components can run in any core-uid process and register receivers as "android"; the exemption from the package-list check is extended from exactly SYSTEM_UID to all core uids.
- Resulting check at android-security-14.0.0_r29 line 13827: `if (!UserHandle.isCore(callerApp.info.uid) && !callerApp.getPkgList().containsKey(callerPackage)) throw new SecurityException(...)`.
Completeness
- The fix is confined to the single check in registerReceiverWithFeature; the deprecated registerReceiver wrapper is covered because it delegates to registerReceiverWithFeature (lines 13802-13807).
- The "android" bypass is removed for all non-core callers; no other package name was special-cased in this hunk.
- The second commit loosens the check for every core uid (not only SYSTEM_UID): core-uid callers can still register with any callerPackage value without the package-list check. This is intended per the commit message, but it means callerPackage is not validated for core uids.
- Other AMS entry points that take a callerPackage string are not touched by these commits; the material does not show whether they have a comparable special case.
Behavior changes
- Non-core-uid callers that pass "android" (or any package not in their process) as callerPackage to registerReceiver/registerReceiverWithFeature now receive a SecurityException instead of a successful registration.
- Callers in core uids other than SYSTEM_UID are newly exempt from the package-list check (previously only SYSTEM_UID was exempt); per the commit message this keeps system components in core-uid processes able to register receivers as "android".
- Warning path at line 13842 (UserHandle.isCore(callingUid) priority check) is unchanged.
Per major
- Android 14: same fix: both commits (d48f297f2165 then 93c036bb67be) applied in android-security-14.0.0_r20; at r29 the patched region shows the final `!UserHandle.isCore(...)` form (4/5 lines present).
- Android 15: same fix for the first commit: 475f9914f716 in android-security-15.0.0_r8 removes the "android" clause with identical diff (line 14688). The material does not show the isCore follow-up on 15; at 15.0.0_r17 only 3/5 lines of the patched region are present, so whether the second commit landed there is unknown.
- Android 16: not affected (not listed by the bulletin); at android-security-16.0.0_r8, 4/5 lines of the patched region are present.
- Android 17: not affected (not listed by the bulletin); at android-security-17.0.0_r1, 4/5 lines of the patched region are present.
Unknowns
- Whether the isCore follow-up (93c036bb67be) was applied on Android 15 (only the first commit is shown for 15).
- Which downstream consumers of the spoofed callerPackage make this EoP per the bulletin; the material only shows the check and its use in isInstantApp and handleIncomingUser, not the receiver record.
- Whether any permission check beyond enforceNotIsolatedCaller gates this path.
- Whether other AMS APIs accepting a callerPackage have a similar "android" special case.