CVE-2024-34739 AI-generated analysis
platform/frameworks/base, system_server USB service (services/usb, UsbProfileGroupSettingsManager)
Adds a USER_SETUP_COMPLETE check in UsbProfileGroupSettingsManager so that the USB device-attached path returns before resolveActivity while the current user's setup is still in progress.
Root cause
In services/usb/java/com/android/server/usb/UsbProfileGroupSettingsManager.java, the device-attached handling path (the method just before deviceAttachedForFixedHandler, ending in resolveActivity(intent, matches, defaultActivity, device, null)) went on to start the resolved handler activity after its earlier early-return checks without consulting Settings.Secure.USER_SETUP_COMPLETE. As a result, an activity could be launched by a USB attach while device setup was still in progress (commit title: 'Restrict USB poups while setup is in progress'). The bulletin rates this High / EoP.
How the fix works
- UsbProfileGroupSettingsManager.java: a new private helper, shouldRestrictOverlayActivities(), reads Settings.Secure.getIntForUser(mContext.getContentResolver(), USER_SETUP_COMPLETE, defaultValue=1, UserHandle.CURRENT.getIdentifier()). If the value is 0 it logs 'restricting usb overlay activities as setup is not complete' via Slog.d and returns true; otherwise it returns false.
- UsbProfileGroupSettingsManager.java: in the device-attached path, immediately before '// Start activity with registered intent' / resolveActivity(intent, matches, defaultActivity, device, null), the fix inserts 'if (shouldRestrictOverlayActivities()) return;'.
- Two imports are added: static android.provider.Settings.Secure.USER_SETUP_COMPLETE and android.provider.Settings. The fix is a single Java-only commit with 21 added lines and no removed lines.
Completeness
- Covers only the one resolveActivity call site in the USB device-attached path (called with device, null). The diff does not change deviceAttachedForFixedHandler(UsbDevice, ComponentName), which begins right after the patched method and also builds a device-attached intent; the rest of its body is not shown.
- The check uses defaultValue=1: if USER_SETUP_COMPLETE is absent for the user, the launch is allowed (fail-open).
- The check is evaluated for UserHandle.CURRENT rather than for the specific user/profile resolved; the material does not show whether these can differ here.
- The launch is suppressed rather than deferred; this diff adds no re-trigger after setup completes.
Behavior changes
- While Settings.Secure.USER_SETUP_COMPLETE == 0 for the current user, a USB device attach handled by this path no longer reaches resolveActivity; Slog.d logs 'restricting usb overlay activities as setup is not complete'.
- No change when the setting is 1 or unset (default 1).
- Adds a Settings.Secure.getIntForUser read before resolveActivity in this path.
Per major
- Android 14: same fix: commit 50e1f8f36e32 in android-security-14.0.0_r11 (cherry-pick of internal 2ce2e54a/71042ac0, Change-Id I7d54534696fd73f3b94c5b4250142eed9341c5d8); at android-security-14.0.0_r29 the patched region is fully present (8/8 lines).
- Android 15: not affected per the bulletin (the bulletin's affected list shows '15-next'); patched region fully present (8/8) at android-security-15.0.0_r17.
- Android 16: not affected per the bulletin; patched region fully present (8/8) at android-security-16.0.0_r8.
- Android 17: not affected per the bulletin; patched region fully present (8/8) at android-security-17.0.0_r1.
Unknowns
- The exact name of the patched method is not visible in the hunk; it is identified by its resolveActivity(..., device, null) call and its position before deviceAttachedForFixedHandler.
- Whether deviceAttachedForFixedHandler or any accessory-attach path also launches activities, and whether separate commits for this CVE gated them.
- The concrete privilege-escalation impact; the bulletin gives only High / EoP.
- Status of Android 13, which the bulletin lists as affected but for which no per-major fact is provided.