CVE-2025-48562 AI-generated analysis

platform/frameworks/base, packages/PrintSpooler (RemotePrintDocument, PDF save/write-out)

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

PrintSpooler's save-to-PDF path now opens the destination content URI in write-truncate mode ("wt") instead of the default mode, so that overwriting an existing file gets a truncated output stream.

Root cause

RemotePrintDocument.writeContent(ContentResolver, Uri) copied the rendered document from the spooler's file into the user-selected destination using contentResolver.openOutputStream(uri), the one-argument form, which does not explicitly request truncation. The commit message says the fix requests a truncated output stream in case the user selects to overwrite an existing file. The inferred consequence is that content of the previous file could remain past the end of the newly written PDF; the material does not show this directly.

How the fix works

• packages/PrintSpooler/src/com/android/printspooler/model/RemotePrintDocument.java:writeContent: contentResolver.openOutputStream(uri) is changed to contentResolver.openOutputStream(uri, "wt"), requesting a truncating write stream before the 8192-byte copy loop writes the document bytes.
• No other logic changes: the acquireFile/FileInputStream source, the copy loop, the IOException logging and the finally block (closeQuietly, releaseFile) are unchanged.

Completeness

• The fix covers the output open in RemotePrintDocument.writeContent, the only openOutputStream call shown in the material.
• The fix does not verify the resulting file length; actual truncation depends on the destination provider honoring "wt".
• IOExceptions are still only logged (Log.e "Error writing document content.") and swallowed in writeContent.

Behavior changes

• When saving to PDF, the destination is opened with mode "wt" (truncate) instead of the default mode, so overwriting an existing file is intended to produce only the new document bytes.

Per major

• Android 14: same fix: platform/frameworks/base a52780f0ce9e in android-security-14.0.0_r22, one-line change in RemotePrintDocument.writeContent; the code context at android-security-14.0.0_r29 shows the "wt" line.
• Android 15: same fix: platform/frameworks/base 252efec89b01 in android-security-15.0.0_r10, identical diff (index bfc00bb8b94d..985482904727); at android-security-15.0.0_r17, 4/5 lines of the patched region are present.
• Android 16: same fix: platform/frameworks/base 177eda822164 in android-security-16.0.0_r1, identical one-line hunk on a different file base (a9d00e9a77eb..287842992bef); at android-security-16.0.0_r8, 4/5 lines of the patched region are present.
• Android 17: not listed by the bulletin (not affected per the bulletin); at android-security-17.0.0_r1, 4/5 lines of the patched region are present. Whether the fixed line is there is not shown.

Unknowns

• The callers of writeContent and the destination providers used are not shown.
• How providers that do not support "wt" behave is not shown.
• Whether Android 13 (listed as affected) received the same patch is not shown.
• Why the per-major facts report 4/5 lines of the patched region present in every branch is not explained; the fixed line is shown only at 14.0.0_r29.
• Whether the fixed line is present at 15.0.0_r17, 16.0.0_r8 and 17.0.0_r1 is not directly shown.

Back to September 2025 · Findings