CVE-2025-48614 AI-generated analysis
platform/frameworks/base, core/java/android/os/RecoverySystem.java (factory reset / recovery system)
RecoverySystem.rebootWipeUserData now throws a SecurityException when DynamicSystemManager.isInUse() reports that the device is running a Dynamic System Update (DSU) image, so a factory reset can no longer be started while in DSU mode.
Root cause
Before sending the MASTER_CLEAR_NOTIFICATION broadcast and starting the wipe, RecoverySystem.rebootWipeUserData only checked the UserManager.DISALLOW_FACTORY_RESET user restriction, and only when force was false. It did not check whether the device was booted into a DSU image, so a user-data wipe could be started in that state. The bulletin rates the consequence as a High severity DoS. The material does not explain how wiping in DSU mode leads to the DoS.
How the fix works
- core/java/android/os/RecoverySystem.java: adds the import android.os.image.DynamicSystemManager.
- core/java/android/os/RecoverySystem.java:rebootWipeUserData: gets DynamicSystemManager via context.getSystemService(Context.DYNAMIC_SYSTEM_SERVICE), next to the existing UserManager lookup.
- core/java/android/os/RecoverySystem.java:rebootWipeUserData: after the existing DISALLOW_FACTORY_RESET check, adds `if (dsuManager.isInUse()) throw new SecurityException("Wiping data is not allowed while in DSU mode.")`. The `force` parameter does not gate this check, so forced wipes are also refused in DSU mode. The throw happens before the ConditionVariable is created and before the MASTER_CLEAR_NOTIFICATION broadcast, so no wipe side effects start.
Completeness
- The fix covers only RecoverySystem.rebootWipeUserData. Every caller that goes through this method, including forced wipes, hits the new check.
- Unlike the DISALLOW_FACTORY_RESET check, the new check does not depend on `force`, so callers cannot skip it through that flag.
- This diff does not touch any other RecoverySystem entry point. The material does not show whether other wipe or recovery paths exist that would need the same guard.
- The result of getSystemService(Context.DYNAMIC_SYSTEM_SERVICE) is used without a null check. If the service were unavailable, the method would fail with a NullPointerException instead of a SecurityException.
Behavior changes
- rebootWipeUserData throws SecurityException("Wiping data is not allowed while in DSU mode.") whenever DynamicSystemManager.isInUse() is true, whatever the force flag and user restrictions are.
- Callers that could previously factory reset while in DSU mode now get a SecurityException from rebootWipeUserData. Per index search, DeviceLockController's DevicePolicyControllerImpl.wipeDevice catches SecurityException from DevicePolicyManager.wipeDevice and returns false. Whether the new exception reaches it through DPMS is not shown.
- Every call now does one extra getSystemService lookup.
Per major
- Android 14: same fix: ed10409eb6de in android-security-14.0.0_r24, applied to the 5-parameter rebootWipeUserData(context, shutdown, reason, force, wipeEuicc). All 8 patched lines are present at android-security-14.0.0_r29.
- Android 15: same fix: aa4b01792c25 in android-security-15.0.0_r12, applied to the 6-parameter signature that includes keepMemtagMode. All 8 lines are present at android-security-15.0.0_r17.
- Android 16: same fix: ec0c32ea736b in android-security-16.0.0_r3, same content as on 15. All 8 lines are present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin). The patched region is present (8/8 lines) at android-security-17.0.0_r1.
Unknowns
- The material does not describe how a factory reset in DSU mode leads to the DoS.
- The material does not show whether other RecoverySystem entry points or wipe paths need the same DSU guard.
- The Android 13 fix commit is not in the material.
- Whether DynamicSystemManager can be null on any configuration (the fix does not null-check it).
- The production call paths into RecoverySystem.rebootWipeUserData (for example from DevicePolicyManagerService) are not shown.