CVE-2024-43764 AI-generated analysis
platform/frameworks/base, SystemUI clipboard overlay (packages/SystemUI/src/com/android/systemui/clipboardoverlay/ClipboardListener.java)
SystemUI's ClipboardListener now checks KeyguardManager.isDeviceLocked() before showing the interactive clipboard overlay, falling back to the non-interactive "copied" toast when the device is locked.
Root cause
In ClipboardListener.onPrimaryClipChanged(), the decision to show the interactive clipboard overlay (via mOverlayProvider / ClipboardOverlayController) was gated only on user setup completion (isUserSetupComplete()) and on clipData being non-null and non-empty. It did not consider the device lock state. Per the commit message, in some situations the clipboard UI could be entered while the device was locked, and the intents it provides could be accessed from there. The commit message states users should not be able to access intents from this state.
How the fix works
- packages/SystemUI/src/com/android/systemui/clipboardoverlay/ClipboardListener.java: a KeyguardManager field (mKeyguardManager) is added and injected through the constructor (new parameter between ClipboardManager and UiEventLogger).
- ClipboardListener.onPrimaryClipChanged(): the existing guard becomes `mKeyguardManager.isDeviceLocked() || !isUserSetupComplete() || clipData == null || clipData.getItemCount() == 0`. When the device is locked the code takes the same branch as the not-setup-complete case: if shouldShowToast(clipData) it shows the toast (ClipboardToast.showCopiedToast, logging CLIPBOARD_TOAST_SHOWN), and the new test verifies that the overlay provider is not used.
- packages/SystemUI/tests/src/com/android/systemui/clipboardoverlay/ClipboardListenerTest.java: adds a mocked KeyguardManager to the constructor call and a new test, test_deviceLocked_showsToast. The test verifies that with isDeviceLocked()==true only the toast is shown and the overlay provider has zero interactions.
Completeness
- The check is added to the existing guard in onPrimaryClipChanged that decides between toast and interactive overlay, so it is evaluated on each clip change that reaches that guard (an earlier early-return in the method is unchanged).
- Uses isDeviceLocked() rather than isKeyguardLocked(). Per the commit message this is intentional: a keyguard that is up but trivially dismissable still gets the interactive overlay.
- The check is evaluated only at clip-change time. The diff adds no handling for the device becoming locked after an overlay is already displayed, and the visible code does not show such a path.
- The toast path is still taken when locked (if shouldShowToast permits), so a 'copied' toast can still appear while locked. Only the interactive overlay is blocked.
Behavior changes
- When the device is locked (credential required) and something is copied, SystemUI shows only the copied toast (CLIPBOARD_TOAST_SHOWN event) instead of the interactive clipboard overlay.
- The ClipboardListener constructor signature changes (adds KeyguardManager), which affects dependency injection and any direct instantiation, such as tests.
Per major
- Android 14: same fix: commit 70eb75df7d34 in android-security-14.0.0_r15 (cherry-pick of 2976ca86d5c5); patched region fully present (8/8 lines) at android-security-14.0.0_r29.
- Android 15: not affected per bulletin; the patched region lines are present (8/8) at android-security-15.0.0_r17.
- Android 16: not affected per bulletin; patched region present (8/8 lines) at android-security-16.0.0_r8.
- Android 17: not affected per bulletin; patched region present (8/8 lines) at android-security-17.0.0_r1.
Unknowns
- The concrete situation in which clipboard UI could be entered while locked (referenced bug b/317048495) is not described in the material.
- The bulletin lists Android 13 as affected, but no Android 13 fix commit, branch status or code is provided, so whether the change applies unchanged there is not shown.
- Behavior if the device locks while an overlay is already showing is not visible in the provided code.