CVE-2025-26462 AI-generated analysis
platform/frameworks/base, services/accessibility (AccessibilityServiceConnection)
Adds an onNullBinding override to AccessibilityServiceConnection that calls unbindLocked() under mLock, so system_server no longer stays bound to an accessibility service whose onBind() returned null and that service can no longer launch activities from the background (BAL).
Root cause
AccessibilityServiceConnection, a ServiceConnection used by system_server, handled onServiceDisconnected but did not override onNullBinding. When an accessibility service returned null from onBind(), nothing in the connection released the binding. Per the commit message, the service therefore stayed bound by system_server and could launch activities from the background.
How the fix works
- services/accessibility/java/com/android/server/accessibility/AccessibilityServiceConnection.java: a new @Override onNullBinding(ComponentName) is added after onServiceDisconnected. It takes mLock and calls unbindLocked(). The comment in the diff says Context#unbindService must be called here to release the tracking resources associated with the ServiceConnection and so prevent BAL.
- No other files change. The fix is a single 10-line addition, and the same hunk is applied on Android 14, 15 and 16; only the line offset differs (@@ -252 on 14, @@ -310 on 15, @@ -309 on 16).
Completeness
- Covers only the onNullBinding path of AccessibilityServiceConnection. onServiceConnected and onServiceDisconnected are unchanged.
- onServiceDisconnected also calls mActivityTaskManagerService.setAllowAppSwitches(mComponentName.flattenToString(), -1, userState.mUserId). The new onNullBinding does not call it directly, and the material does not show whether unbindLocked() clears that allowance.
- The body of unbindLocked() is not in the material, so exactly what it releases cannot be confirmed from the diff.
Behavior changes
- An accessibility service whose onBind() returns null is now unbound by system_server instead of staying bound.
- Such a service can no longer launch activities from the background (per the commit message and its test description).
- No API change or new error code is visible in the diff. The change is limited to system_server's handling of the connection.
Per major
- Android 14: same fix: commit 7076b2b2bd3c in android-security-14.0.0_r21 (cherry-pick, Change-Id Id04111b061881d23346aa90a0b5d08a28bed2c6f). Patched region fully present at android-security-14.0.0_r29.
- Android 15: same fix: commit af2f9c246ef0 in android-security-15.0.0_r9, identical hunk at a different offset. Patched region fully present at android-security-15.0.0_r17.
- Android 16: same fix: commit eeac12b27c64 in android-16.0.0_r2, identical hunk. Patched region fully present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin). The patched region is present at android-security-17.0.0_r1.
Unknowns
- The implementation of unbindLocked() is not shown, so the exact resources it releases, including whether it resets the setAllowAppSwitches allowance, cannot be confirmed.
- How and when system_server binds an accessibility service (for example, after the user enables it) is not shown.
- Which BAL check the lingering binding satisfied is not shown. Only the commit message states the outcome.
- The content of the CTS test Bug_386950836 and the reproduction steps in bug 386950836 are not included.