CVE-2025-0099 AI-generated analysis

platform/frameworks/base, CompanionDeviceManagerService (services/companion)

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

Adds a SYSTEM_UID calling-UID check to the CompanionDeviceManagerService binder methods getBackupPayload and applyRestoredPayload, so callers that are not the system UID are rejected with a SecurityException.

Root cause

In services/companion/java/com/android/server/companion/CompanionDeviceManagerService.java, the binder stub overrides getBackupPayload(int userId) and applyRestoredPayload(byte[] payload, int userId) passed calls straight to mBackupRestoreProcessor without checking who the caller was. Both methods take a userId supplied by the caller. The commit title ('Check for system calling UID when backing up and restoring data') indicates these operations are meant only for system callers. The material does not show whether the processor enforces any access control of its own.

How the fix works

• CompanionDeviceManagerService.java, getBackupPayload(int userId) in the binder stub: a guard `if (getCallingUid() != SYSTEM_UID) throw new SecurityException("Caller must be system")` is inserted before the call to mBackupRestoreProcessor.getBackupPayload(userId).
• CompanionDeviceManagerService.java, applyRestoredPayload(byte[] payload, int userId): the same guard is inserted before the call to mBackupRestoreProcessor.applyRestoredPayload(payload, userId).
• The check is a strict UID equality test against SYSTEM_UID, not a permission check. Single commit.

Completeness

• Both stub entry points shown in the diff that forward to mBackupRestoreProcessor are now gated. In the surrounding context shown, no other stub method forwards to it directly.
• The guard sits only in the binder stub and mBackupRestoreProcessor itself is unchanged. handleShellCommand passes mBackupRestoreProcessor to CompanionDeviceShellCommand, and that path's access control is not shown in the material.
• The check does not validate userId; it relies entirely on the caller being system.

Behavior changes

• getBackupPayload and applyRestoredPayload now throw SecurityException("Caller must be system") for any caller whose UID is not SYSTEM_UID.
• No change for callers running as SYSTEM_UID.

Per major

• Android 14: Not affected per the bulletin. At android-security-14.0.0_r29 only 1/4 lines of the patched region are present, which suggests the code differs there. No fix applied.
• Android 15: Same fix: commit 7946586c3350 landed in android-security-15.0.0_r5 (cherry-picked from 692cddfb32ab). 4/4 lines are present at android-security-15.0.0_r17.
• Android 16: Not affected per the bulletin. 4/4 lines of the patched region are present at android-security-16.0.0_r8.
• Android 17: Not affected per the bulletin. 4/4 lines of the patched region are present at android-security-17.0.0_r1.

Unknowns

• Whether mBackupRestoreProcessor.getBackupPayload/applyRestoredPayload perform any access checks of their own, and what data the payload contains, is not shown in the material.
• Whether other callers of mBackupRestoreProcessor (e.g. CompanionDeviceShellCommand) are gated separately is not shown.
• Which callers could invoke these methods before the fix (e.g. whether the AIDL layer enforces anything) is not shown.
• The content of the original commit 692cddfb32ab, beyond this cherry-pick, is not provided.

Back to February 2025 · Findings