Heap-buffer-overflow in mp3dec_ex_read_frame via Integer Underflow (Distinct from #140)
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 50/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- c
- Domain
- audio-video-rtc, security
Research direction
Start in minimp3_ex.h around line 940, where buf_size is computed as end_offset - dec->offset; trace how dec->offset is set in mp3dec_ex_seek and used in mp3dec_ex_read_frame (line 943). The crash path goes through mp3dec_decode_frame into mp3d_find_frame and hdr_valid in minimp3.h, so read those to see how the oversized buf_size reaches the decoder. For verification, compile with -fsanitize=address and run the reporter's PoC MP3 through mp3dec_ex_read_frame; done means the offset validation prevents the underflow and no ASan report appears.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- C
- Stars
- 2k
- Forks
- 271
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lieff/minimp3
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
[Bug]signed left-shift overflow in mp3dec_skip_id3v1 when parsing the APEv2 tag-size field (CWE-190)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Integer overflow in Xing/Info VBR header parsing leads to ~10TB allocation (DoS)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 Half a day Newbie friendliness 30/100
-
Difficulty 4/5 3-5 days Newbie friendliness 40/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
ly05010419/MacNativeGames#1340 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
InukaAsith/TwinDesk#84 ·
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day