CVE-2025-26425 AI-generated analysis

platform/packages/modules/Permission, role management service (RoleService, IRoleManager binder)

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

Adds an SDK-level precondition (SdkLevel.isAtLeastU()) at the top of RoleService's binder methods getDefaultApplicationAsUser and setDefaultApplicationAsUser so they throw IllegalStateException instead of executing when the Permission module runs on a platform below Android 14 (API 34).

Root cause

RoleService.getDefaultApplicationAsUser and setDefaultApplicationAsUser are the service side of RoleManager.getDefaultApplication/setDefaultApplication. Per index search, those client methods are annotated @RequiresPermission(MANAGE_DEFAULT_APPLICATIONS) and @RequiresApi(UPSIDE_DOWN_CAKE). The fix's own comment says the MANAGE_DEFAULT_APPLICATIONS permission is only available on U+. The service methods did not check that the platform was U or newer. So when the updatable Permission module ran on an older platform (the new CTS test targets SDK S through T), the binder methods could still be reached and ran their logic: the cross-user check, the user existence check, then the role default-application get/set. This happened without the intended U+ permission guarantee. The material does not show the exact permission-enforcement code inside these methods.

How the fix works

• service/java/com/android/role/RoleService.java:getDefaultApplicationAsUser (inner IRoleManager stub): adds Preconditions.checkState(SdkLevel.isAtLeastU(), "This API is only available on Android 34 and above") as the first statement, before UserUtils.enforceCrossUserPermission and the UserUtils.isUserExistent check.
• service/java/com/android/role/RoleService.java:setDefaultApplicationAsUser: adds the same Preconditions.checkState(SdkLevel.isAtLeastU(), ...) as the first statement, before enforceCrossUserPermission and the user existence check.
• service/java/com/android/role/RoleService.java: adds import com.android.modules.utils.build.SdkLevel. Only the Android 14 commit adds this import; the Android 15 diff does not add it, so the file already had it. com.android.internal.util.Preconditions was already imported.
• The Android 15 commit also adds tests/cts/role/src/android/app/role/cts/RoleManagerSecurityTest.kt. It contains two @AsbSecurityTest(cveBugId=379362792) tests, limited by SdkSuppress to S through TIRAMISU, that check getDefaultApplication/setDefaultApplication throw NoSuchMethodError or IllegalStateException on pre-U platforms.

Completeness

• Covers exactly the two binder entry points getDefaultApplicationAsUser and setDefaultApplicationAsUser in RoleService. The check is unconditional and comes before all other logic in both methods.
• Does not change the client-side RoleManager.getDefaultApplication/setDefaultApplication wrappers (framework-s) or the underlying permission enforcement. The gate is based only on SDK level.
• The fix does not touch other IRoleManager methods in RoleService. The material does not show whether any of them depend on a U+-only permission in the same way.
• The Android 14 commit shown does not include the CTS test file. Only the Android 15 commit adds RoleManagerSecurityTest.kt.

Behavior changes

• On platforms where SdkLevel.isAtLeastU() is false (API 33 and below), both binder methods now throw IllegalStateException ("This API is only available on Android 34 and above") right away. A client calling through RoleManager gets this exception instead of a result or callback.
• On U and newer platforms nothing changes: the check passes and execution continues as before.
• The check runs before enforceCrossUserPermission. On pre-U platforms, callers therefore get IllegalStateException instead of a SecurityException for cross-user violations.

Per major

• Android 14: same fix: commit 8ae31de10c7c (RESTRICT AUTOMERGE cherry-pick, Change-Id Iadc97d09cf083e2525de421362c5a4bece92ee8a) in android-security-14.0.0_r20. It adds the SdkLevel import and the two checkState calls. 8/8 patched lines are present at android-security-14.0.0_r29.
• Android 15: same fix: commit 850ce9ea3ac7 in android-security-15.0.0_r8 with the same checkState lines (SdkLevel import already present), plus the new CTS test RoleManagerSecurityTest.kt. 8/8 lines are present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin). 6/8 lines of the patched region are present at android-security-16.0.0_r8; the material does not show the exact form of the code there.
• Android 17: not affected (not listed by the bulletin). 6/8 lines of the patched region are present at android-security-17.0.0_r1; the material does not show the exact form of the code there.

Unknowns

• The material does not show the permission-enforcement code inside getDefaultApplicationAsUser/setDefaultApplicationAsUser, that is, how MANAGE_DEFAULT_APPLICATIONS is checked and how that behaves on pre-U platforms.
• The material does not explain why the bulletin lists 14, 15 and 15-next as affected while the fix and its test target platforms below U.
• The state of the patched region on Android 16/17 (6/8 lines present) and whether the check exists there in a different form.

Back to May 2025 · Findings