CVE-2025-48616 AI-generated analysis

platform/frameworks/base, SystemUI keyguard (KeyguardViewMediator / KeyguardUpdateMonitor)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (9 corrections). Verify against the commit before relying on it.

KeyguardViewMediator now queries KeyguardUpdateMonitor.isUserInLockdown instead of LockPatternUtils.isUserInLockdown at the three places that decide whether lockdown forces the keyguard to show or prevents it from being hidden.

Root cause

KeyguardViewMediator decided lockdown handling with mLockPatternUtils.isUserInLockdown(...). Its onStrongAuthStateChanged callback is invoked by KeyguardUpdateMonitor.notifyStrongAuthAllowedChanged (per index search), and per the commit message the LockPatternUtils view of lockdown may be out of sync with the KeyguardUpdateMonitor's strong auth tracker. When they disagreed, onStrongAuthStateChanged would not call doKeyguardLocked, setKeyguardEnabled(false) would not be overridden by lockdown, and the keyguard show path would skip showing because the keyguard was externally disabled. The commit's test scenario is pinning an app, locking down the device and checking that the keyguard always shows (repeated 10 times).

How the fix works

• packages/SystemUI/src/com/android/systemui/keyguard/KeyguardViewMediator.java: the KeyguardUpdateMonitorCallback's onStrongAuthStateChanged now calls mUpdateMonitor.isUserInLockdown(current user) instead of mLockPatternUtils.isUserInLockdown before doKeyguardLocked(null).
• KeyguardViewMediator.java: setKeyguardEnabled path (the '!enabled && mShowing' branch) now uses mUpdateMonitor.isUserInLockdown to decide to log 'keyguardEnabled(false) overridden by user lockdown' and return without hiding.
• KeyguardViewMediator.java: the 'if another app is disabling us, don't show' condition (doKeyguard path) now uses mUpdateMonitor.isUserInLockdown so lockdown still forces the keyguard even when mExternallyEnabled is false.
• packages/SystemUI/src/com/android/keyguard/KeyguardUpdateMonitorCallback.java: javadoc of onStrongAuthStateChanged updated to direct implementers to use KeyguardUpdateMonitor (e.g. isUserInLockdown) as the source of truth. No code change.
• packages/SystemUI/tests/src/com/android/systemui/keyguard/KeyguardViewMediatorTest.java: tests onLockdown_showKeyguard_evenIfKeyguardIsNotEnabledExternally and doNotHideKeyguard_whenLockdown_onKeyguardNotEnabledExternally now mock mUpdateMonitor.isUserInLockdown instead of mLockPatternUtils.isUserInLockdown.

Completeness

• All three lockdown checks in the diffed regions of KeyguardViewMediator (onStrongAuthStateChanged, setKeyguardEnabled, doKeyguard path) are switched to mUpdateMonitor; no mLockPatternUtils.isUserInLockdown call remains in the diffed regions.
• The fix does not change how either LockPatternUtils or KeyguardUpdateMonitor computes lockdown state, nor does it make the two sources consistent; it only uses the monitor as the source in this class.
• Other KeyguardUpdateMonitorCallback implementers that may consult LockPatternUtils for lockdown are addressed only by the javadoc guidance; the material does not show whether any exist.
• Other mLockPatternUtils uses in KeyguardViewMediator shown in context (isSecure, getDevicePolicyManager in the biometric callbacks) are unchanged and are not lockdown checks.

Behavior changes

• Lockdown is now evaluated from KeyguardUpdateMonitor when onStrongAuthStateChanged fires, intended so the keyguard shows when lockdown starts even while the keyguard is externally disabled (e.g. app pinned, per commit test).
• setKeyguardEnabled(false) is refused (with the existing log line) whenever the monitor reports lockdown, independent of LockPatternUtils state.
• No new APIs, flags, or error codes; Flag: EXEMPT CVE_FIX.

Per major

• Android 14: same fix: 991998d5464f in android-security-14.0.0_r24, three call sites use KeyguardUpdateMonitor.getCurrentUser(); the shown code context at android-security-14.0.0_r29 contains the fixed onStrongAuthStateChanged and test lines; resolver reports 6/8 lines of the patched region present.
• Android 15: adapted fix: 9adff3df0285 in android-security-15.0.0_r12, same three sites but user id comes from mSelectedUserInteractor.getSelectedUserId() with wrapped lines; same javadoc and test changes; 6/8 lines present at android-security-15.0.0_r17.
• Android 16: adapted fix: aa9fbb1b74eb in android-security-16.0.0_r3, same shape as the Android 15 version (mSelectedUserInteractor.getSelectedUserId()); 6/8 lines present at android-security-16.0.0_r8.
• Android 17: same fix as the 14 variant: 52a6d6dfda83 (RESTRICT AUTOMERGE) in android-17.0.0_r1, using KeyguardUpdateMonitor.getCurrentUser() call sites; resolver reports 6/8 lines of the patched region present at android-security-17.0.0_r1.

Unknowns

• Why LockPatternUtils and the strong auth tracker get out of sync (the implementation of either isUserInLockdown is not in the material).
• Whether other KeyguardUpdateMonitorCallback implementers still use LockPatternUtils for lockdown decisions.
• Exact reason the resolver reports 6/8 lines present in the latest tags.

Back to June 2026 · Findings