CVE-2025-48599 AI-generated analysis

platform/packages/apps/Settings, Wi-Fi (WifiScanModeActivity, handler for WifiManager.ACTION_REQUEST_SCAN_ALWAYS_AVAILABLE)

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 (11 corrections). Verify against the commit before relying on it.

Settings' WifiScanModeActivity now finishes immediately, without showing the "allow scanning when Wi-Fi is off" dialog, when the current user has the DISALLOW_CONFIG_LOCATION user restriction.

Root cause

WifiScanModeActivity.createDialog() built and showed the AlertDialogFragment, which lets the user approve "scan always available" for a requesting app, after only its existing early-return checks. Of those checks, only a trailing 'return;' is visible in the diff. The method never called UserManager.hasUserRestriction(UserManager.DISALLOW_CONFIG_LOCATION), so a user under that restriction could still see the scan-mode dialog and accept it.

How the fix works

• src/com/android/settings/wifi/WifiScanModeActivity.java:createDialog(): after the existing early-return checks and before the 'if (mDialog == null)' dialog creation, the fix adds 'if (!isWifiScanModeConfigAllowed(getApplicationContext())) { Log.e(...); finish(); return; }'. onCreate() calls createDialog() after both the fresh-intent branch and the savedInstanceState restore branch, so both paths reach the new gate.
• src/com/android/settings/wifi/WifiScanModeActivity.java: adds a new private static helper isWifiScanModeConfigAllowed(Context). It gets UserManager from the context and returns !userManager.hasUserRestriction(UserManager.DISALLOW_CONFIG_LOCATION). If UserManager is unavailable it returns true (allow).
• src/com/android/settings/wifi/WifiScanModeActivity.java:isGuestUser(): removes the 'if (context == null) return false;' guard and keeps the UserManager null guard. The rest of the diff (onCreate, AlertDialogFragment.onCreateDialog, field declarations) only changes formatting, with no logic change.

Completeness

• The fix gates this activity's dialog path in createDialog(), which onCreate() reaches from both branches. The material does not show the whole file.
• Only DISALLOW_CONFIG_LOCATION is checked. No other user restriction is checked here, and the material does not show whether that is intended.
• The new helper fails open: if context.getSystemService(UserManager.class) returns null, the activity treats the user as allowed. isGuestUser() behaves the same way, since it returns false (not a guest) when UserManager is null.
• The check is a UI-side gate in Settings. The material does not show whether the action taken in doPositiveClick() enforces the restriction on its own.

Behavior changes

• When the user has DISALLOW_CONFIG_LOCATION, launching WifiScanModeActivity now logs 'This user is not allowed to configure Wi-Fi Scan Mode!' at error level and finishes without showing the dialog. The new block calls no setResult, so the requesting app gets no positive result.
• No change for users without the restriction. Apart from formatting, the dialog and its allow/deny handling are unchanged.
• isGuestUser() would now throw a NullPointerException if passed a null context, where it used to return false. The material does not show its callers.

Per major

• Android 14: same fix: commit b263af44716e cherry-picked into android-security-14.0.0_r24 (Change-Id If8cfb7047c0131da451a7af0d2b5108080876b85). All 8/8 lines of the patched region are present at android-security-14.0.0_r29.
• Android 15: not affected per the bulletin. The patched region (8/8 lines) is present at android-security-15.0.0_r17.
• Android 16: not affected per the bulletin's per-major listing, although the bulletin's affected versions include '16-qpr2-next'. The patched region (8/8 lines) is present at android-security-16.0.0_r8.
• Android 17: not affected per the bulletin. The patched region (8/8 lines) is present at android-security-17.0.0_r1.

Unknowns

• What the early-return checks before the new block in createDialog() contain (the diff context shows only the trailing 'return;').
• Whether the source changes (7a792e0b8f68 / a42e722b0775) included tests or other files that this cherry-pick does not carry.
• Whether the action taken by doPositiveClick() enforces DISALLOW_CONFIG_LOCATION on the service side.
• Which user's restriction getApplicationContext() checks in multi-user setups.
• Why the bulletin lists Android 13 as affected when the material includes no Android 13 fix commit.

Back to December 2025 · Findings