CVE-2026-0014 AI-generated analysis
platform/frameworks/base, services/core AppOps (AppOpsService)
Adds an early `Process.isSdkSandboxUid(uid)` check to the attribution-tag validation helper in AppOpsService, so that for a non-null packageName the helper returns false for SDK sandbox UIDs instead of treating them as trusted/system.
Root cause
In services/core/java/com/android/server/appop/AppOpsService.java, the boolean helper used for attribution tag validation (its name is not shown in the hunk header) returns true for a null packageName. It then returns true when `UserHandle.getAppId(uid)` is in the system range (`appId > 0 && appId < Process.FIRST_APPLICATION_UID`), and otherwise continues with further logic not shown in the material. It had no handling for SDK sandbox UIDs. Per the commit message, sandboxed UIDs could therefore be considered "system" for the purposes of attribution tag validation. The bulletin classifies the impact as DoS (High). The fix's test, AppOpsMemoryUsageTest, suggests the consequence concerns AppOps memory usage, but the material does not describe the mechanism.
How the fix works
- services/core/java/com/android/server/appop/AppOpsService.java, attribution-tag validation helper (not named in the material, around line 3959 on Android 14): the fix inserts `if (Process.isSdkSandboxUid(uid)) { return false; }` after the existing `if (packageName == null) return true;` and before the `appId < Process.FIRST_APPLICATION_UID` system check.
- Effect: for any SDK sandbox UID with a non-null packageName, the helper now returns false right away (untrusted). Neither the system-appId branch nor the remaining validation logic can classify a sandbox UID as trusted.
- Single commit, single hunk, three added lines. The change is identical in all three fixed branches (Android 14 7320b5316d76, Android 15 531f3ac25912, Android 16 b51a58ecec96).
Completeness
- The fix covers only this one helper in AppOpsService. Sandbox UIDs are rejected after the null-packageName check and before the system-appId check.
- The `packageName == null` early return true still comes before the new check, so a sandbox UID with a null packageName still returns true. The material does not show whether that path is reachable.
- The rest of the helper's body (after the system-appId check) is not shown, so the material does not tell which downstream condition originally caused sandbox UIDs to be treated as system.
- This change touches no other AppOps trust/validation paths. The material does not show whether sibling helpers perform a similar uid-range-based trust check.
Behavior changes
- Attribution tag validation now returns false for all SDK sandbox UIDs with a non-null packageName, where previously it could return true.
- The diff adds no exceptions, error codes or API changes; only the boolean result for sandbox callers changes.
- The change is unconditional (Flag: EXEMPT CVE_FIX), not behind a feature flag.
Per major
- Android 14: same fix: 7320b5316d76 in android-security-14.0.0_r25 (cherry-pick of internal 1bc6b146 / 8714d11f); 3/3 patched lines present at android-security-14.0.0_r29.
- Android 15: same fix: 531f3ac25912 in android-security-15.0.0_r13, identical three-line hunk at a different line offset (~4718); 3/3 lines present at android-security-15.0.0_r17.
- Android 16: same fix: b51a58ecec96 in android-security-16.0.0_r4, identical three-line hunk (~5043); 3/3 lines present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin); the patched region (3/3 lines) is present at android-security-17.0.0_r1.
Unknowns
- The name of the patched helper function and its callers (the hunk header only shows the class; the supplied code context is a different region of the file).
- The code path after the system-appId check that originally led to sandbox UIDs being treated as system.
- The concrete DoS mechanism (the test name AppOpsMemoryUsageTest hints at memory usage, but the material does not state it).
- Whether the null-packageName early return can be reached by a sandbox UID.