CVE-2023-40094 AI-generated analysis
platform/frameworks/base, WindowManager / ActivityTaskManagerService (keyguard control)
Adds a CONTROL_KEYGUARD permission check to the IActivityTaskManager.keyguardGoingAway binder entry point in ActivityTaskManagerService so that callers without that permission can no longer signal that the keyguard is going away.
Root cause
ActivityTaskManagerService.keyguardGoingAway(int flags), the implementation of the binder method IActivityTaskManager.keyguardGoingAway, only called enforceNotIsolatedCaller("keyguardGoingAway") before clearing the calling identity and continuing. No permission was required, so any non-isolated process with access to the ActivityTaskManager binder could call this keyguard-going-away notification, which per index search is normally sent by SystemUI's KeyguardViewMediator. The rest of the method body is not shown; per index search, KeyguardController.keyguardGoingAway (which marks the keyguard as going away and prepares the TRANSIT_KEYGUARD_GOING_AWAY transition) is the likely downstream path.
How the fix works
- services/core/java/com/android/server/wm/ActivityTaskManagerService.java:keyguardGoingAway: adds mAmInternal.enforceCallingPermission(CONTROL_KEYGUARD, "unlock keyguard") as the first statement, before enforceNotIsolatedCaller and before Binder.clearCallingIdentity, so the check runs against the real caller's identity. A static import of android.Manifest.permission.CONTROL_KEYGUARD is added.
- core/java/android/app/IActivityTaskManager.aidl:keyguardGoingAway: adds @JavaPassthrough(annotation="@android.annotation.RequiresPermission(android.Manifest.permission.CONTROL_KEYGUARD)"), which marks the permission requirement on the generated Java interface.
Completeness
- Covers the single binder entry point IActivityTaskManager.keyguardGoingAway, which is the only unguarded path shown in the material.
- The internal KeyguardController.keyguardGoingAway(displayId, flags) is not changed. Per index search it is package-private and called from DisplayContentTests; that ATMS calls it is not shown in the material.
- The neighbouring keyguard-related AIDL method setLockScreenShown in the same interface is not touched by this commit; its enforcement is not shown in the material.
Behavior changes
- Callers of IActivityTaskManager.keyguardGoingAway without android.permission.CONTROL_KEYGUARD now receive a SecurityException instead of having the request processed (enforceCallingPermission throws SecurityException on denial) (general platform knowledge).
- The permission check now runs before the isolated-caller check, so an isolated process without the permission fails on the permission check first.
- Legitimate callers such as SystemUI KeyguardViewMediator (per index search) are unaffected provided they hold CONTROL_KEYGUARD.
Per major
- Android 14: same fix: commit fa30b150bba0 in android-security-14.0.0_r3 (Change-Id I7ba7e56f954c8e6f1f734311f735215918975bc6); 8/8 patched lines present at android-security-14.0.0_r29.
- Android 15: not affected per the bulletin; the patched region is present at android-security-15.0.0_r17 (8/8 lines).
- Android 16: not affected per the bulletin; patched region present at android-security-16.0.0_r8 (8/8 lines).
- Android 17: not affected per the bulletin; patched region present at android-security-17.0.0_r1 (8/8 lines).
Unknowns
- The material does not show the concrete impact of an unprivileged keyguardGoingAway call beyond the bulletin's EoP/High rating.
- The body of ActivityTaskManagerService.keyguardGoingAway after clearCallingIdentity is not shown, so neither the exact downstream call nor any validation of flags is shown.
- Whether the backports to Android 11, 12, 12L and 13 (listed as affected) were applied identically is not shown; only the Android 14 commit is provided.
- Enforcement on the sibling AIDL method setLockScreenShown is not shown in the material.