CVE-2025-26448 AI-generated analysis

platform/frameworks/base, libs/androidfw CursorWindow (android.database cursor window native backing)

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

Replaces malloc with calloc for the inline CursorWindow data buffer in CursorWindow::create() so the buffer is zero-initialized before it can be parcelled to a remote process.

Root cause

CursorWindow::create() allocated the inline window buffer (mSize = min(kInlineSize=16384, inflatedSize)) with malloc(window->mSize), leaving the bytes uninitialized. Per the commit message, the caller might not fully fill that buffer before sending it to the remote end, so uninitialized heap contents of the creating process could be transmitted. The commit message says createFromParcel() does not need zeroing because its buffer is immediately filled from the far end.

How the fix works

• libs/androidfw/CursorWindow.cpp:CursorWindow::create(): change `window->mData = malloc(window->mSize);` to `window->mData = calloc(window->mSize, 1);` so every byte of the inline buffer is zero before window->clear() and updateSlotsData() run and before any later writes or parcelling. The failure check (`if (!window->mData) goto fail;`) is unchanged.

Completeness

• Covers only the inline (heap) buffer allocated in CursorWindow::create(). This is the single allocation the commit identifies as reaching the remote end partially filled.
• CursorWindow::createFromParcel() is intentionally left unchanged; the commit message states its buffer is immediately filled from the far end.
• This diff does not touch the ashmem-backed buffer allocated in CursorWindow::maybeInflate() (which starts at line 75 of the context; its body is not shown). The material does not show whether that buffer needed zeroing.

Behavior changes

• Inline CursorWindow buffers (up to 16 KiB) are now zero-filled at allocation, with a slight extra cost from calloc versus malloc.
• No API, error code, or control-flow change; failure handling is identical.

Per major

• Android 14: same fix: platform/frameworks/base 3c1515f4d194 in android-security-14.0.0_r21 (one-line malloc->calloc in CursorWindow::create), cherry-picked from 9dc64621d896 per its commit message; 6/6 lines of the patched region present at android-security-14.0.0_r29.
• Android 15: same fix: platform/frameworks/base b7d9d1744c4f in android-security-15.0.0_r9, identical diff; 6/6 lines present at android-security-15.0.0_r17.
• Android 16: same fix: platform/frameworks/base 9dc64621d896 in android-16.0.0_r2; 6/6 lines present at android-security-16.0.0_r8.
• Android 17: not affected: not listed by the bulletin; the calloc line is present at android-security-17.0.0_r1 (6/6 lines).

Unknowns

• The material does not show which caller or Java-side path leaves the inline buffer partially filled before parcelling.
• The material does not show whether the maybeInflate() ashmem path needs zeroing or was assessed separately.
• No Android 13 fix commit is present in the material, although the bulletin lists 13 as affected.
• The Android 15 commit message is not shown in full, so its cherry-pick origin is not confirmed.

Back to June 2025 · Findings