CVE-2025-48590 AI-generated analysis
platform/frameworks/base, services/core AppOps (AppOpsService)
Removes the Q- app compat exemption in AppOpsService attribution tag validation. An attribution tag not declared by the package (or whose package is not found) is no longer forced to valid when SECURITY_EXCEPTION_ON_INVALID_ATTRIBUTION_TAG_CHANGE is disabled for the package or calling UID.
Root cause
In services/core/java/com/android/server/appop/AppOpsService.java, the attribution tag validation path builds an error message when the tag is not declared by the package or the package is not found. Before the fix it then queried mPlatformCompat.isChangeEnabledByPackageName(SECURITY_EXCEPTION_ON_INVALID_ATTRIBUTION_TAG_CHANGE, packageName, userId) and isChangeEnabledByUid(..., callingUid). If either returned false (the 'Q- apps' exemption named in the commit title), it set isAttributionTagValid = true and only logged an error. Invalid tags from such callers were therefore treated as valid.
How the fix works
- services/core/java/com/android/server/appop/AppOpsService.java, attribution tag validation method (hunk at ~line 3937 on 14; method name not shown in the hunk header): the try/catch block that consulted mPlatformCompat for SECURITY_EXCEPTION_ON_INVALID_ATTRIBUTION_TAG_CHANGE and set isAttributionTagValid = true is deleted, and only Slog.e(TAG, msg) remains. isAttributionTagValid is therefore no longer overridden to true when the tag is undeclared or the package is not found.
- The now-unused static import of android.app.AppOpsManager.SECURITY_EXCEPTION_ON_INVALID_ATTRIBUTION_TAG_CHANGE is removed from AppOpsService.java. No other file is touched.
Completeness
- The fix covers the single place in AppOpsService.java where the compat exemption overrode the validation result.
- The diff does not show how callers consume isAttributionTagValid (whether an invalid tag is replaced, dropped, or rejected), so the material cannot confirm downstream handling; it only shows that the validation result is no longer forced to true.
- Any other users of SECURITY_EXCEPTION_ON_INVALID_ATTRIBUTION_TAG_CHANGE outside this file are not touched by this commit; the material does not show whether any exist.
Behavior changes
- Apps for which SECURITY_EXCEPTION_ON_INVALID_ATTRIBUTION_TAG_CHANGE is disabled (by package name or UID) now have undeclared attribution tags, or tags for a package that is not found, treated as invalid; previously they were forced to valid.
- The Slog.e error log is still emitted in the same cases; the compat query and its RemoteException catch are gone.
- The hunk itself adds no new exception or error code; the effect on callers of an invalid result is not shown in the material.
Per major
- Android 14: same fix: commit 0c46a5ec453b in android-security-14.0.0_r24 (import removal + deletion of the compat try/catch) at ~line 3937; 7/8 lines of the patched region present at android-security-14.0.0_r29.
- Android 15: same fix: commit 529f24023e15 in android-security-15.0.0_r12, same change at ~line 4692; 7/8 lines of the patched region present at android-security-15.0.0_r17.
- Android 16: same fix: commit 848f94492175 in android-security-16.0.0_r3, same change at ~line 5017; 7/8 lines of the patched region present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin); 7/8 lines of the patched region present at android-security-17.0.0_r1.
Unknowns
- The name of the enclosing validation method and the public AppOpsService entry points that call it are not shown.
- How callers react to isAttributionTagValid == false is not shown, so the precise pre- and post-fix handling of an invalid tag is unknown.
- The resource exhaustion mechanism is only implied by the bulletin type (DoS) and the test name AppOpMemoryUsageTest; the affected data structure is not shown.