CVE-2026-45524 AI-generated analysis
platform/packages/modules/Wifi, WifiPermissionsUtil (Wi-Fi service permission checks)
WifiPermissionsUtil#isSystem now returns false for Private Compute Core UIDs (when SdkLevel.isAtLeastC()), so PCC callers are no longer treated as system apps for Wi-Fi permission decisions.
Root cause
WifiPermissionsUtil.isSystem(packageName, uid) decided system-app status only by looking up ApplicationInfo for the package/uid and testing APP_INFO_FLAGS_SYSTEM_APP. The only UID-class exclusion was for SDK sandbox UIDs (Process.isSdkSandboxUid on T+). Private Compute Core UIDs were not excluded, so a PCC caller whose package resolved to a system-flagged ApplicationInfo was treated as a system app for Wi-Fi permissions, which the commit message says should not happen.
How the fix works
- service/java/com/android/server/wifi/util/WifiPermissionsUtil.java:isSystem: after the existing isSdkSandboxUid exclusion and before the PackageManager lookup, adds `if (SdkLevel.isAtLeastC() && Process.isPrivateComputeCoreUid(uid))`, which logs a warning and returns false. Like the sandbox check, it runs inside the Binder.clearCallingIdentity/restoreCallingIdentity block.
- service/tests/wifitests/src/com/android/server/wifi/util/WifiPermissionsUtilTest.java: adds testIsSystem covering the sandbox UID (T+), the PCC UID (C+), a system app flag, a non-system app, and NameNotFoundException. Process is mocked statically for the UID-class cases and PackageManager is mocked for the ApplicationInfo cases.
Completeness
- Covers only the isSystem helper. The PCC exclusion comes before the ApplicationInfo lookup, so it applies whatever flags the package has.
- The exclusion is gated on SdkLevel.isAtLeastC(). On devices where this returns false, the check is skipped and behavior is unchanged.
- The commit message says the behavior is tied to the enablePccFrameworkSupport flag, but the diff shows no flag read. The only gate in the code is SdkLevel.isAtLeastC().
- Other permission helpers in WifiPermissionsUtil are not shown in the material and this commit does not touch them. The material does not show whether any of them classify PCC UIDs on their own.
Behavior changes
- On builds where SdkLevel.isAtLeastC() is true, isSystem returns false for any UID for which Process.isPrivateComputeCoreUid(uid) is true, even if the resolved ApplicationInfo has a system-app flag.
- A new Log.w line 'isSystem: isPrivateComputeCoreUid, returning false' is emitted when the exclusion triggers.
- Any Wi-Fi service path that relied on isSystem to grant system-only treatment now denies it to PCC callers.
Per major
- Android 14: not affected per the bulletin; at android-security-14.0.0_r30, 4/6 lines of the patched region are present (the material does not show which lines are missing); no fix applied
- Android 15: not affected per the bulletin; at android-security-15.0.0_r18, 4/6 lines of the patched region are present (which lines are missing is not shown); no fix applied
- Android 16: not affected per the bulletin; at android-security-16.0.0_r9, 4/6 lines of the patched region are present (which lines are missing is not shown); no fix applied
- Android 17: same fix: commit 78ed57915792 (cherry-pick of fc70c981d930) in android-security-17.0.0_r1; all 6/6 patched lines present at android-security-17.0.0_r2
Unknowns
- Which Wi-Fi service entry points call isSystem, and what data or capability a PCC caller obtained through system-app status (the bulletin only states type ID, High).
- How the enablePccFrameworkSupport flag mentioned in the commit message relates to the code; the diff shows only the SdkLevel.isAtLeastC() gate.
- Which Android release SdkLevel C corresponds to; the material does not state it.
- Which lines of the patched region are missing on 14, 15 and 16.
- Whether the original commit fc70c981d930 differs from the cherry-pick.