CVE-2024-34742 AI-generated analysis

platform/frameworks/base, services/devicepolicy (device policy owner state persistence, OwnersData)

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.

Makes DeviceOwnerReadWriter.shouldWrite() in OwnersData always return true, so the device owner persistence file (device_owners2.xml) is always written. Before, it was written only when a device owner, system update policy or system update info was set.

Root cause

In services/devicepolicy/java/com/android/server/devicepolicy/OwnersData.java, DeviceOwnerReadWriter.shouldWrite() returned true only if mDeviceOwner, mSystemUpdatePolicy or mSystemUpdateInfo was non-null. writeInner() also serializes other state. mDeviceOwnerTypes (TAG_DEVICE_OWNER_TYPE entries) is visible, and there is more content after line 385 that the material does not show. If the three checked fields were all null while other state existed, shouldWrite() returned false and the file was not written, so that state was not persisted. The commit was tested by upgrading from T-QPR3 ("Test: Manual, upgrading from T-QPR3").

How the fix works

• OwnersData.java:DeviceOwnerReadWriter.shouldWrite(): the three-field null check is replaced with `return true;`. The device owner file is now always written, whichever fields are populated.
• writeInner() and the read path are unchanged. What gets written is the same; only the decision whether to write changes.

Completeness

• Because the condition is now unconditional, the fix covers every field writeInner() serializes for the device owner file, not just mDeviceOwnerTypes.
• Only DeviceOwnerReadWriter is changed. The material shows neither the sibling profile owner read/writer nor what the FileReadWriter base class does when shouldWrite() returns false, so it cannot show whether a similar condition exists elsewhere.

Behavior changes

• device_owners2.xml is now written on every device owner write, including when there is no device owner, system update policy or system update info. In that case it holds whatever writeInner() produces for the populated fields, e.g. device owner types.
• Possibly more disk writes in the device policy service. The diff changes no API and no error codes.

Per major

• Android 14: Same fix: commit 688e5c3012eb in android-security-14.0.0_r11 (cherry-pick of internal 3abc0742, Change-Id I7a7dba56). At android-security-14.0.0_r29 the code shows `return true;` in shouldWrite() (1/3 lines of the patched region).
• Android 15: Not affected per the bulletin. android-security-15.0.0_r17 has 2/3 lines of the patched region; the material does not explain this.
• Android 16: Not affected per the bulletin. android-security-16.0.0_r8 has 1/3 lines of the patched region; the code at this tag is not shown.
• Android 17: Not affected per the bulletin. android-security-17.0.0_r1 has 1/3 lines of the patched region; the code at this tag is not shown.

Unknowns

• The material does not show the exact user-visible DoS effect, i.e. what fails when the device owner file is not written.
• The material does not show what the FileReadWriter base class does when shouldWrite() returns false (skip the write or delete the existing file).
• The material does not explain why android-security-15.0.0_r17 has 2/3 lines of the patched region while 14, 16 and 17 have 1/3, or how the 15/16/17 code came to its current form.
• The material does not show whether the profile owner counterpart has a similar condition.

Back to August 2024 · Findings