CVE-2023-21245 AI-generated analysis
platform/frameworks/base, SystemUI keyguard (packages/SystemUI/src/com/android/keyguard/KeyguardSecurityContainerController.java)
Changes the SIM PIN/PUK shortcut in SystemUI's KeyguardSecurityContainerController so the bouncer is finished only when the target user's security mode is None AND (the lockscreen is disabled for the current user or the target user's setup is incomplete), instead of when the security mode is None OR the lockscreen is disabled.
Root cause
In KeyguardSecurityContainerController, the SimPin/SimPuk case ("Shortcut for SIM PIN/PUK to go to directly to user's security screen or home") set finish = true (BOUNCER_DISMISS_SIM) when securityMode == SecurityMode.None || mLockPatternUtils.isLockScreenDisabled(KeyguardUpdateMonitor.getCurrentUser()). The condition did not consider whether the target user's setup was complete. Per the commit message, the intent is that when user setup is not complete the device should not go to the lockscreen even if the lockscreen is not disabled. The diff also changes the OR to an AND; the material does not state which of these changes addresses the vulnerability.
How the fix works
- packages/SystemUI/src/com/android/keyguard/KeyguardSecurityContainerController.java, SimPin/SimPuk case: computes boolean isLockscreenDisabled = mLockPatternUtils.isLockScreenDisabled(KeyguardUpdateMonitor.getCurrentUser()) || !mDeviceProvisionedController.isUserSetup(targetUserId), and changes the finish condition to (securityMode == SecurityMode.None && isLockscreenDisabled).
- Same file: adds a DeviceProvisionedController dependency (new import, final field mDeviceProvisionedController, new @Inject constructor parameter placed after UserSwitcherController and assigned in the constructor) so the controller can query isUserSetup(targetUserId).
- packages/SystemUI/tests/src/com/android/keyguard/KeyguardSecurityContainerControllerTest.java: updates the constructor call to pass mock(DeviceProvisionedController.class); no new test method appears in the shown diff despite the commit message saying 'add Unit test'.
Completeness
- Only the SimPin/SimPuk shortcut in the security-mode switch is changed; no other keyguard dismissal path is touched in this commit.
- isLockScreenDisabled() is still evaluated for KeyguardUpdateMonitor.getCurrentUser() while getSecurityMode() and isUserSetup() use targetUserId; the fix does not unify these user ids, but the AND now requires the target user's security mode to be None.
- The new isUserSetup(targetUserId) term only affects the result when securityMode is None; it cannot by itself cause the shortcut to finish when the target user's security mode is not None.
- The shown test diff only adapts the constructor call; coverage of the new condition is not visible in the material.
Behavior changes
- After SIM PIN/PUK handling, the shortcut no longer finishes the bouncer for a target user whose security mode is not None, even if isLockScreenDisabled(currentUser) returns true.
- When the target user's security mode is None and user setup is incomplete, the shortcut finishes the bouncer even if the lockscreen is not flagged disabled (commit test: wipe device, auth SIM PIN in setup, observe no lockscreen).
- When the target user's security mode is None, user setup is complete and the lockscreen is not disabled, the shortcut no longer sets finish; the code path taken instead is not shown in the material.
- KeyguardSecurityContainerController's @Inject constructor gains a DeviceProvisionedController parameter; manual construction (e.g. tests) must be updated.
Per major
- Android 14: same fix: commit 710dfb62f479 (DO NOT MERGE, cherry-pick of 448f1b18a783) in android-security-14.0.0_r4; at android-security-14.0.0_r29 8/8 lines of the patched region are present.
- Android 15: not affected per the bulletin; patched region (8/8 lines) present at android-security-15.0.0_r17.
- Android 16: not affected per the bulletin; patched region (8/8 lines) present at android-security-16.0.0_r8.
- Android 17: not affected per the bulletin; patched region (8/8 lines) present at android-security-17.0.0_r1.
Unknowns
- Which part of the condition change (OR to AND, or the added isUserSetup term) addresses the vulnerability, and the exact trigger behind the High EoP rating.
- The enclosing method name is not visible in the diff hunk header.
- The code path taken when the shortcut does not finish.
- The fix commits for Android 11, 12, 12L and 13 and any differences in those branches.
- Whether a dedicated unit test for the new condition exists beyond the constructor change shown.