CVE-2025-0094 AI-generated analysis
platform/packages/apps/Settings, users / multi-user settings (UserSettings fragment)
Adds a `!mUserManager.isProfile()` condition to UserSettings.onCreateOptionsMenu so that a profile (e.g. a work profile) that manages to open the UserSettings screen is no longer offered the "Remove this user" overflow menu item.
Root cause
In src/com/android/settings/users/UserSettings.java, onCreateOptionsMenu built the MENU_REMOVE_USER overflow item whenever the current user was not an admin, could switch users now, and was not a guest. That condition did not consider whether the current user is a profile. Per the commit message, profiles are not expected to open Settings at all, but if UserSettingsActivity is launched as a profile (the test line uses `am start --user 10` for the work profile) the overflow would appear, and onOptionsItemSelected routes MENU_REMOVE_USER to onRemoveUserClicked(UserHandle.myUserId()), i.e. a user-removal flow driven from a profile context.
How the fix works
- src/com/android/settings/users/UserSettings.java:onCreateOptionsMenu: the guard `!isCurrentUserAdmin() && canSwitchUserNow() && !isCurrentUserGuest()` is extended with `&& !mUserManager.isProfile()`, so when the fragment runs in a profile the MENU_REMOVE_USER item (and its DISALLOW_REMOVE_USER admin-restriction decoration) is never added to the menu.
- No other code is changed; onOptionsItemSelected and onRemoveUserClicked are untouched. The fix relies on the menu item not existing rather than on a check in the selection handler.
Completeness
- Covers only the creation of the overflow menu item in UserSettings.onCreateOptionsMenu; this is a single-line condition change.
- onOptionsItemSelected (lines 484-492 in the r29 context) still dispatches MENU_REMOVE_USER to onRemoveUserClicked(UserHandle.myUserId()) with no isProfile() check of its own; it is reached only via the menu item, which is now not created for profiles, so from the code shown the path is closed but there is no defense in depth at the handler.
- The commit message says profiles are not expected to open Settings at all; this change does not prevent the profile from launching UserSettingsActivity, it only hides the overflow item once there. Whether other preferences on the same screen behave correctly in a profile context is not shown in the material.
Behavior changes
- When UserSettings is displayed as a profile user, the overflow (options) menu no longer contains the "Remove this user" item; for non-profile secondary users the menu is unchanged.
- No new error, toast, or log; purely a UI gating change.
Per major
- Android 14: same fix: commit 795cdea6838a in android-security-14.0.0_r17 ([DO NOT MERGE] cherry-pick of 69c7f5dac580); the patched condition appears at android-security-14.0.0_r29 (lines 467-468 of the context), with the per-major check reporting 4/5 lines of the patched region present.
- Android 15: same fix: commit c86bccb4e1d3 in android-security-15.0.0_r5, identical one-line condition change at the same location (hunk offset 463 vs 464); 4/5 lines of the patched region present at android-security-15.0.0_r17.
- Android 16: not affected (not listed by the bulletin); 4/5 lines of the patched region present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin); 4/5 lines of the patched region present at android-security-17.0.0_r1.
Unknowns
- The material does not show the Android 12/12L/13 fix commits, only that the bulletin lists those versions as affected.
- The material does not show what onRemoveUserClicked does when invoked for a profile's own user id, so the concrete consequence of the pre-fix path (beyond the bulletin's High EoP rating) is not established here.
- Why the per-major check reports 4/5 lines of the patched region rather than 5/5 is not explained, although the r29 context shows the fixed condition intact; no code context is shown for 15/16/17 tags.