CVE-2025-48619 AI-generated analysis

platform/frameworks/base, core/java/android/content/ContentProvider.java (ContentProvider.Transport, content provider file access)

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

ContentProvider's binder Transport now sanitizes the file open mode string in openFile and openAssetFile, silently removing the truncate ('t') and append ('a') flags when the write ('w') flag is absent, before both the permission check and the call into the provider.

Root cause

In ContentProvider.Transport.openFile and Transport.openAssetFile, the mode String supplied by the caller was passed unchanged to enforceFilePermission(attributionSource, uri, mode) and then to mInterface.openFile / mInterface.openAssetFile. The new code comment lists the supported modes as r, w, wt, wa, rw, rwt, but nothing normalized other combinations. A mode containing 't' (truncate) or 'a' (append) without 'w' therefore reached the provider implementation as a read request that carried bits able to modify the file. The commit message describes this as preventing unintended changes. Presumably the permission check treated such a mode as a read, but the body of enforceFilePermission is not shown. The bulletin rates the issue as High severity EoP.

How the fix works

• core/java/android/content/ContentProvider.java: a new private helper Transport.validateFileMode(String mode) is added. If mode is non-null and contains no 'w', it removes every 't' (mode.replace("t", "")) and every 'a' (mode.replace("a", "")) and returns the result. Modes containing 'w' and null modes are returned unchanged.
• core/java/android/content/ContentProvider.java: Transport.openFile computes final String updatedMode = validateFileMode(mode) after validateIncomingUri/maybeGetUriWithoutUserId. It then passes updatedMode to enforceFilePermission and to mInterface.openFile, so the permission check and the provider see the same sanitized mode.
• core/java/android/content/ContentProvider.java: Transport.openAssetFile gets the same change, passing updatedMode to enforceFilePermission and mInterface.openAssetFile.
• The code comment in validateFileMode explains the design choice: unsupported modes are not rejected with a SecurityException, to avoid app compatibility issues. Instead, bits that allow modifying files are silently dropped when the write bit is absent. The commit message references atest CtsContentProviderTestCases.

Completeness

• Covers both Transport entry points changed by the diff that accept a String mode: openFile and openAssetFile. Both now feed the sanitized mode to the permission check and the provider.
• Only the 't' and 'a' characters are stripped. Other unexpected characters in the mode string still pass through unchanged, and the comment says a strict allow-list was deliberately not implemented.
• The sanitization is added only in Transport. The material does not show whether other call paths to a provider's openFile/openAssetFile exist or need it.
• Transport.update, which is visible in the context, takes no mode String and is unaffected. openTypedAssetFile is not shown in the material, so its handling is unknown.

Behavior changes

• Mode strings without 'w' lose their 't' and 'a' characters before reaching the provider. For example, mode "rt" or "ra" is delivered to the provider as "r". No exception is thrown and no error is returned to the caller.
• enforceFilePermission now runs on the sanitized mode instead of the raw string from the caller.
• Modes that contain 'w' (w, wt, wa, rw, rwt) and null modes are unchanged.

Per major

• Android 14: same fix: platform/frameworks/base f54544f81d7d in android-security-14.0.0_r24 (cherry-pick of f8099b069367df749a4c101b5d7f9020d83cb660, Change-Id I1a8993d99d1f381e1122b304d223a5c10e4578ce). At android-security-14.0.0_r29, 7/8 lines of the patched region are present, and the code context shows validateFileMode wired into openFile and openAssetFile.
• Android 15: same fix: platform/frameworks/base e623c490905c in android-security-15.0.0_r12. The diff is identical except that the context lines use TRACE_TAG_ACTIVITY_MANAGER instead of TRACE_TAG_DATABASE. At android-security-15.0.0_r17, 7/8 lines of the patched region are present.
• Android 16: same fix: platform/frameworks/base 31e77d73c5e6 in android-security-16.0.0_r3, with a diff identical to 15. At android-security-16.0.0_r8, 7/8 lines of the patched region are present.
• Android 17: not affected: Android 17 is not listed by the bulletin. At android-security-17.0.0_r1, 6/8 lines of the patched region are present. The material does not show the exact code there.

Unknowns

• The body of enforceFilePermission is not in the material, so how it maps the mode string to read or write permission checks is inferred, not shown.
• Whether Transport.openTypedAssetFile or any other path accepts a mode-like parameter is not shown.
• Whether in-process or other non-Transport call paths into a provider's openFile/openAssetFile need the same sanitization is not shown.
• The exact state of the patched region on android-security-17.0.0_r1 (6/8 lines) is not shown.

Back to March 2026 · Findings