CVE-2025-48627 AI-generated analysis
platform/frameworks/base, WindowManager / ActivityTaskManagerService (activity start, background activity launch checks)
In ActivityTaskManagerService.startNextMatchingActivity, the fix saves the real Binder caller (uid/pid) before the calling identity is cleared. It then passes them to the ActivityStarter as realCallingUid/realCallingPid instead of r.launchedFromUid / -1, so the background activity launch (BAL) decision is made against the app that actually calls the method. It also removes the earlier setAvoidMoveToFront() workaround from b/230492947.
Root cause
startNextMatchingActivity built the ActivityStarter with setRealCallingUid(r.launchedFromUid) and setRealCallingPid(-1). launchedFromUid is the uid of the app that launched the calling activity (for example the Launcher), and that app may hold BAL privileges. Per the commit message, using this identity as the real caller lets the next matching activity be launched with the launching app's BAL standing instead of the calling app's. An earlier mitigation (b/230492947) forced setAvoidMoveToFront() on the options. The commit message says this broke the legitimate ability to start a new task via startNextMatchingActivity and did not address the identity problem.
How the fix works
- services/core/java/com/android/server/wm/ActivityTaskManagerService.java:startNextMatchingActivity: reads Binder.getCallingUid() and Binder.getCallingPid() into origCallingUid/origCallingPid before Binder.clearCallingIdentity(), which preserves the identity of the process that invoked the Binder method.
- Same function: the ActivityStarter chain now uses .setRealCallingPid(origCallingPid) and .setRealCallingUid(origCallingUid) instead of .setRealCallingPid(-1) and .setRealCallingUid(r.launchedFromUid). Per the in-code comment, ActivityStarter ignores callingUid/callingPid when setCaller(r.app.getThread()) is set, so both the effective callingUid and realCallingUid now resolve to the calling app.
- Same function: the line options.getOptions(r).setAvoidMoveToFront() (the b/230492947 workaround) is removed. The options object is still created via SafeActivityOptions(ActivityOptions.makeBasic()) when it is null.
Completeness
- Covers the single call site in startNextMatchingActivity that passed r.launchedFromUid as the real caller. realCallingUid/realCallingPid now reflect the actual Binder caller.
- setCallingUid(r.launchedFromUid), setCallingPackage(r.launchedFromPackage) and setCallingFeatureId(r.launchedFromFeatureId) are unchanged. The commit relies on ActivityStarter ignoring callingUid/callingPid when a caller is set. callingPackage and featureId still carry the launching app's values, and the diff does not touch them.
- The fix removes the previous setAvoidMoveToFront() restriction, so the BAL check with the corrected identity is what governs this launch path.
- The commit modifies no other ActivityTaskManagerService entry points.
Behavior changes
- BAL checks for startNextMatchingActivity now use the uid/pid of the app calling the method rather than the uid that launched its activity.
- setAvoidMoveToFront() is no longer forced on the options, so startNextMatchingActivity can again start a new task, which is the behavior the commit title says it restores.
- realCallingPid is now a real pid instead of -1. The TODO(b/64750076) comment about -1 remains for callingPid.
Per major
- Android 14: same fix: commit 07561c7d685d (RESTRICT AUTOMERGE cherry-pick of d34ae40f870d, Change-Id Ia8c6123e8e9325d17d2bfab9589b11eb087da97a) in android-security-14.0.0_r24. At android-security-14.0.0_r29, 6/8 lines of the patched region are present. The origCallingUid/origCallingPid capture and setRealCallingPid(origCallingPid) are visible, but the starter is assigned to a local `starter` variable and setRealCallingPid directly follows setCallingPid(-1).
- Android 15: not affected (not listed by the bulletin). At android-security-15.0.0_r17, 6/8 lines of the patched region are present.
- Android 16: not affected (Android 16 is not listed by the bulletin; the bulletin does list 16-qpr2-next). At android-security-16.0.0_r8, 6/8 lines of the patched region are present.
- Android 17: not affected (not listed by the bulletin). At android-security-17.0.0_r1, 5/8 lines of the patched region are present.
Unknowns
- Why the bulletin lists 16-qpr2-next as affected while android-security-16.0.0_r8 already shows most of the patched region. The material does not include a diff for the 16 branch.
- Whether the 15/16/17 code carries the corrected identity handling. Only partial line-match counts are given.
- Whether setCallingUid still uses r.launchedFromUid in the android-security-14.0.0_r29 code. The context excerpt stops after setRealCallingPid.
- Whether the Android 13 fix (13 is listed as affected by the bulletin) is identical. No Android 13 commit is included in the material.