CVE-2025-48524 AI-generated analysis

platform/packages/modules/Wifi, Wi-Fi service permission checks (WifiPermissionsUtil)

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

WifiPermissionsUtil.isSystem() now returns false early when the calling uid is an SDK sandbox uid (on T+), instead of deriving system-app status from the ApplicationInfo flags of the supplied package name.

Root cause

WifiPermissionsUtil.isSystem(packageName, uid) decided whether a binder caller is a system app solely by looking up ApplicationInfo for the given packageName under the user derived from uid and testing APP_INFO_FLAGS_SYSTEM_APP. It never checked whether uid itself was an SDK sandbox uid, so a sandbox caller could be classified as a system app. The commit title ('Do not treat SdkSandBox as privileges App') says this classification led the service to treat such callers as privileged apps.

How the fix works

• service/java/com/android/server/wifi/util/WifiPermissionsUtil.java:isSystem - inside the try block, before the PackageManager lookup, adds `if (SdkLevel.isAtLeastT() && Process.isSdkSandboxUid(uid)) return false;`, so a sandbox uid is never classified as a system app, whatever package name is passed in.
• The check runs after Binder.clearCallingIdentity() and inside the existing try/finally, so the calling identity is still restored on the early return.
• The SdkLevel.isAtLeastT() guard means the new check is skipped before T; on pre-T the method behaves exactly as before.

Completeness

• Only isSystem() is hardened; the fix is a single 3-line addition in one method.
• Other identity-based checks in the same class that are visible in the context (isDeviceOwner, isProfileOwnerOfOrganizationOwnedDevice, isOrganizationOwnedDeviceAdmin) are untouched; the material does not show whether they have a similar issue.
• The fix does not change how packageName is validated against uid in isSystem(); it only short-circuits for sandbox uids.
• Where SdkLevel.isAtLeastT() is false, the new check is not executed.

Behavior changes

• Any Wi-Fi service path that consults WifiPermissionsUtil.isSystem() now treats SDK sandbox callers as non-system apps on Android T and later; such callers fall through to the handling that applies to non-system apps.
• No new exception or error code is introduced; the method simply returns false earlier.

Per major

• Android 14: same fix: commit 980d442c5926 in android-security-14.0.0_r22 (cherry-pick of the same Change-Id); 5/5 patched lines present at android-security-14.0.0_r29.
• Android 15: same fix: commit 298745e0cb23 in android-security-15.0.0_r10, identical diff; 5/5 lines present at android-security-15.0.0_r17.
• Android 16: same fix: commit c47809aec031 in android-security-16.0.0_r1, identical diff; 5/5 lines present at android-security-16.0.0_r8.
• Android 17: not affected: not listed by the bulletin; the patched code is present (5/5 lines) at android-security-17.0.0_r1.

Unknowns

• Which Wi-Fi service APIs call isSystem() and what privileged behaviour they gate; the material does not show the callers.
• How packageName is validated against the calling uid before isSystem() is reached (the catch comment references checkPackage, but that code is not shown).
• Why the bulletin classifies the impact as DoS; the diff alone only shows the privilege misclassification.
• The Android 13 fix commit, if any, is not in the material.

Back to September 2025 · Findings