CVE-2025-22434 AI-generated analysis
platform/frameworks/base, services/core WindowManager policy (PhoneWindowManager keyboard shortcuts)
Adds isUserSetupComplete() and !keyguardOn conditions to the Meta+I keyboard shortcut in PhoneWindowManager so showSystemSettings() is no longer invoked while the keyguard is showing or before user setup completes.
Root cause
In services/core/java/com/android/server/policy/PhoneWindowManager.java, the KEYCODE_I case of the system keyboard-shortcut switch called showSystemSettings() whenever the key was down with Meta pressed. It did not check the keyguardOn state that is already available in that switch (the KEYCODE_APP_SWITCH case uses it), and it did not check isUserSetupComplete(). As a result, a Meta+I keypress could open the Settings app on the keyguard without user authentication, which is what the commit title describes. The bulletin rates this as a High severity EoP.
How the fix works
- services/core/java/com/android/server/policy/PhoneWindowManager.java, KEYCODE_I case of the keyboard shortcut switch (the material does not show the name of the enclosing method): the condition `down && event.isMetaPressed()` becomes `down && event.isMetaPressed() && isUserSetupComplete() && !keyguardOn`. If either new condition fails, the case reaches `break` instead of calling showSystemSettings() and returning key_consumed.
- Android 15 variant (c4183cc97a18): the same condition is added to the same KEYCODE_I case. On 15 the guard is `firstDown` instead of `down`, and the handled branch also calls logKeyboardSystemsEvent(event, KeyboardLogEvent.LAUNCH_SYSTEM_SETTINGS) and returns true.
Completeness
- Covers only the Meta+I (KEYCODE_I) shortcut path to showSystemSettings(). It is a single-line condition change and does not modify showSystemSettings() itself.
- Other shortcuts in the same switch shown in the context (KEYCODE_A launchAssistAction, KEYCODE_N toggleNotificationPanel / sendSystemKeyToStatusBarAsync, KEYCODE_T toggleTaskbar, KEYCODE_H/ENTER handleHomeShortcuts, KEYCODE_RECENT_APPS showRecentApps) are not modified by this commit and do not test keyguardOn at the switch level. The material does not show whether their callees enforce keyguard state internally.
- The fix relies on the keyguardOn value computed by the caller and adds no check inside showSystemSettings(). Any other caller of showSystemSettings() is therefore unaffected (the material shows none).
Behavior changes
- Meta+I no longer opens the Settings app while the keyguard is showing. This case does not consume the key event and reaches break.
- Meta+I is also ignored until user setup is complete (until isUserSetupComplete() returns true).
- The Android 14 variant adds no new error, log line or toast. On Android 15 the LAUNCH_SYSTEM_SETTINGS keyboard log event is also skipped when the shortcut is blocked.
Per major
- Android 14: Same fix: 2880f0ab2dc6 in android-security-14.0.0_r19 adds `&& isUserSetupComplete() && !keyguardOn` to the KEYCODE_I case. 4/4 lines of the patched region are present at android-security-14.0.0_r29.
- Android 15: Adapted fix: c4183cc97a18 in android-security-15.0.0_r7 applies the same condition to the Android 15 form of the case (`firstDown`, plus logKeyboardSystemsEvent and `return true`). 4/4 lines of the patched region are present at android-security-15.0.0_r17.
- Android 16: Not affected: the bulletin does not list Android 16. 2/4 lines of the patched region are present at android-security-16.0.0_r8.
- Android 17: Not affected: the bulletin does not list Android 17. 1/4 lines of the patched region are present at android-security-17.0.0_r1.
Unknowns
- The name of the enclosing method that contains the keycode switch is not shown in the material.
- Whether showSystemSettings() has other callers, and whether the callees of sibling shortcuts (launchAssistAction, toggleNotificationPanel, toggleTaskbar, handleHomeShortcuts) check keyguard state internally.
- How the Android 16/17 code differs from the patched region (only 2/4 and 1/4 of its lines are present there).