CVE-2024-0040 AI-generated analysis

platform/frameworks/av, media/mtp (libmtp, MtpPacket)

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

MtpPacket::setParameter now calls allocate(mPacketSize) when it grows mPacketSize, so the buffer is reallocated before putUInt32 writes the parameter at the new offset.

Root cause

In media/mtp/MtpPacket.cpp, MtpPacket::setParameter computes offset = MTP_CONTAINER_PARAMETER_OFFSET + (index - 1) * sizeof(uint32_t). If mPacketSize is smaller than offset + sizeof(uint32_t), it raises mPacketSize to that value. The code then called putUInt32(offset, value) without reallocating the packet buffer, so the logical packet size could exceed the allocated buffer when the write happened. The commit message says this directly: the buffer size was not changed when the packet size was increased.

How the fix works

• media/mtp/MtpPacket.cpp:MtpPacket::setParameter: the single-line if becomes a block. After mPacketSize = offset + sizeof(uint32_t) is assigned, the fix adds allocate(mPacketSize) before putUInt32(offset, value) runs.
• The index range check (index < 1 || index > 5) and the offset computation are unchanged. Only the growth path gains the reallocation.

Completeness

• Covers the only place in the shown code where mPacketSize is increased (MtpPacket::setParameter). The putUInt32 write is now preceded by allocate(mPacketSize).
• The implementation of allocate() is not in the material, so the code shown does not tell us whether it keeps existing buffer contents or how it handles a size no larger than the current buffer.
• MtpPacket::getParameter (same file) still reads getUInt32 at MTP_CONTAINER_PARAMETER_OFFSET + (index - 1) * sizeof(uint32_t). It checks only that the index is in 1..5 and does not compare against mPacketSize or the buffer size. The fix does not touch it.
• The other putUInt16/putUInt32 users in the file (setContainerCode, setTransactionID) write at fixed header offsets and are unchanged.

Behavior changes

• When setParameter grows the packet past its current size, it now calls allocate(mPacketSize). No new error codes or return values are introduced.
• There may be an extra allocation on the setParameter growth path.

Per major

• Android 14: same fix: commit 2ca6c27dc033 in android-security-14.0.0_r5 (cherry-pick of e1494a2d8e7e). 4/4 lines of the patched region are present at android-security-14.0.0_r29.
• Android 15: not affected per the bulletin. The fixed code (allocate(mPacketSize) in setParameter) is present at android-security-15.0.0_r17 (4/4 lines).
• Android 16: not affected per the bulletin. The fixed code is present at android-security-16.0.0_r8 (4/4 lines).
• Android 17: not affected per the bulletin. The fixed code is present at android-security-17.0.0_r1 (4/4 lines).

Unknowns

• The implementation of MtpPacket::allocate is not in the material: whether it copies existing data, whether it can shrink the buffer, and how it tracks the buffer size.
• The material does not show which MtpServer/MtpDevice paths call setParameter on a packet whose mPacketSize is below the parameter offset.
• How other code uses mPacketSize after it has grown is not shown.
• The bulletin type is ID (information disclosure). The material does not show the exact disclosure path, only the size/buffer mismatch in setParameter.

Back to February 2024 · Findings