CVE-2024-23704 AI-generated analysis

platform/packages/apps/Settings, Wi-Fi settings (WifiDialogActivity)

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

WifiDialogActivity.onCreate now also finishes immediately when the user has the DISALLOW_ADD_WIFI_CONFIG user restriction, in addition to the existing DISALLOW_CONFIG_WIFI check.

Root cause

WifiDialogActivity.onCreate gated the activity only on isConfigWifiAllowed(), which checks the DISALLOW_CONFIG_WIFI user restriction. The separate DISALLOW_ADD_WIFI_CONFIG restriction was never consulted, so a user subject to that restriction could still be shown the Wi-Fi configuration dialog this activity hosts. That bypassed the device policy meant to prevent adding Wi-Fi configurations.

How the fix works

• src/com/android/settings/wifi/WifiDialogActivity.java:isAddWifiConfigAllowed (new, @VisibleForTesting): gets UserManager via getSystemService. It returns false (and logs with Log.e) if userManager != null and hasUserRestriction(DISALLOW_ADD_WIFI_CONFIG) is true. Otherwise it returns true.
• src/com/android/settings/wifi/WifiDialogActivity.java:onCreate: the early-exit condition after super.onCreate changes from `if (!isConfigWifiAllowed())` to `if (!isConfigWifiAllowed() || !isAddWifiConfigAllowed())`. When either restriction is set, the activity calls finish() and returns.
• tests/robotests/src/com/android/settings/wifi/WifiDialogActivityTest.java: adds two Robolectric tests, isAddWifiConfigAllowed_hasNoUserRestriction_returnTrue and isAddWifiConfigAllowed_hasUserRestriction_returnFalse. Both mock mUserManager.hasUserRestriction(DISALLOW_ADD_WIFI_CONFIG).

Completeness

• Adds the current user's DISALLOW_ADD_WIFI_CONFIG check to the early exit in WifiDialogActivity.onCreate. The material does not show whether other code paths in the activity (for example a re-delivered intent) can show the dialog without going through onCreate.
• If UserManager is null, the new method returns true (allowed), which is a permissive fallback. The material does not show how isConfigWifiAllowed handles that case.
• Only this activity is changed. The material does not show whether other Settings entry points that create Wi-Fi configurations enforce DISALLOW_ADD_WIFI_CONFIG, so coverage beyond WifiDialogActivity is unknown.

Behavior changes

• WifiDialogActivity finishes immediately in onCreate for users with DISALLOW_ADD_WIFI_CONFIG, and callers get no dialog.
• New error log line: "The user is not allowed to add Wi-Fi configuration."

Per major

• Android 14: same fix: commit 2e90322bab7d in android-security-14.0.0_r7 (cherry-pick of 51fa3d798ad0, RESTRICT AUTOMERGE). At android-security-14.0.0_r29, 7/8 lines of the patched region are present, and the DISALLOW_ADD_WIFI_CONFIG import is visible in the code context.
• Android 15: not affected per the bulletin. At android-security-15.0.0_r17, 7/8 lines of the patched region are present. The line that differs is not identified.
• Android 16: not affected per the bulletin. At android-security-16.0.0_r8, 7/8 lines of the patched region are present.
• Android 17: not affected per the bulletin. At android-security-17.0.0_r1, 7/8 lines of the patched region are present.

Unknowns

• Whether WifiDialogActivity is exported, and how an unprivileged caller reaches it (not shown in the material).
• Which of the 8 patched lines differs in the latest security tags (the per-major facts only report 7/8 present).
• Whether a matching fix for Android 13 exists. The bulletin lists 13 as affected, but no 13 commit is in the material.
• Whether the dialog can be shown through activity paths other than onCreate.

Back to April 2024 · Findings