Heap-buffer-overflow in mp3dec_ex_read_frame via Integer Underflow (Distinct from #140)

[izumi-hyun]

Summary

While analyzing minimp3, I discovered a heap out-of-bounds read reachable through mp3dec_ex_read_frame.

I am aware of Issue #140, which identifies a signed shift UB in VBR tag parsing that leads to a massive memory allocation (DoS). However, this report identifies a distinct trigger path and a separate flaw in the library's read/seek logic.

Even if the VBR parsing UB is fixed, the lack of bounds validation in mp3dec_ex_read_frame may still allow malformed metadata to place the decoder into an invalid state. During analysis, I observed that crafted metadata combined with mp3dec_ex_seek can cause an unsigned integer underflow in the remaining-buffer calculation. This condition appears to contribute to a subsequent heap out-of-bounds read during frame decoding.

Root Cause and The Flaw

The issue involves the remaining buffer size calculation in minimp3_ex.h:

// minimp3_ex.h:940
uint64_t buf_size = end_offset - dec->offset;

When mp3dec_ex_seek is called on a crafted file, dec->offset can exceed end_offset. Because there is no validation that end_offset >= dec->offset, this results in an unsigned integer underflow and produces an unexpectedly large buf_size value (for example, 18446744073709551534).

During debugging, I observed end_offset = 192 and dec->offset = 274 immediately prior to the crash. This underflow condition appears to contribute to the subsequent out-of-bounds read observed in the decoding path.

Crucial Note on Patching: Fixing the VBR tag parsing issue discussed in #140 addresses only one trigger condition. A robust fix should also validate offset relationships before calculating buf_size (for example, by ensuring end_offset >= dec->offset).

Crash Details

==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x512000000152 at pc 0x5d90651498e9
READ of size 1 at 0x512000000152 thread T0
    #0 0x5d90651498e8 in hdr_valid minimp3.h:266:12
    #1 0x5d9065123882 in mp3d_find_frame minimp3.h:1676:13
    #2 0x5d9065120fec in mp3dec_decode_frame minimp3.h:1731:13
    #3 0x5d9065143c55 in mp3dec_ex_read_frame minimp3_ex.h:943:35
    #4 0x5d906514623c in mp3dec_ex_read minimp3_ex.h:1003:31

(GDB confirms end_offset = 192 and dec->offset = 274 at the time of the crash.)

Impact & Next Steps

This issue results in a reproducible heap out-of-bounds read when processing a crafted MP3 file.

The observed impact is a decoder crash under AddressSanitizer. Depending on how the library is embedded and used by downstream applications, out-of-bounds reads may also have information disclosure implications.

I have submitted a CVE request to MITRE regarding this issue. Please let me know if you need the full PoC file to verify a fix.

Best regards
izumi-hyun