Submit #769840: gpac MP4Box MP4Box - GPAC version 2.5-DEV-rev2167-gcc9d617c0-master and earlier Stack-based Buffer Overflow

Vulnerability Details: A stack-based buffer overflow vulnerability exists in the swf_def_bits_jpeg function within GPAC's scene_manager/swf_parse.c. The vulnerability arises because the program uses sprintf to write into a fixed-size stack buffer szName[1024] without validating the length of read->localPath.

An attacker can trigger this overflow by providing a long directory path (e.g., via the command line or a crafted environment) when processing a SWF file. Since read->localPath can be controlled by the user, a path exceeding the buffer limits will overwrite the stack, as confirmed by AddressSanitizer (ASan) showing a WRITE of size 1100 into a 1024-byte buffer.

Impact: This vulnerability could lead to a Denial of Service (DoS) through application crashes. In certain environments, it could potentially be leveraged for Remote Code Execution (RCE) by overwriting the return address on the stack.

Reproduction Steps:

Compile GPAC with AddressSanitizer enabled (--enable-sanitizer).

Create a deeply nested directory structure to exceed 1024 bytes:
export LONG_NAME=$(python3 -c "print('A'*250 + '/' + 'B'*250 + '/' + 'C'*250 + '/' + 'D'*250)")
mkdir -p $LONG_NAME && cp test.swf $LONG_NAME/

Run MP4Box to process the file:
MP4Box -add $PWD/$LONG_NAME/test.swf test.mp4

Observe the ASan error: ERROR: AddressSanitizer: stack-buffer-overflow on address...

Suggested Fix: Replace the unsafe sprintf with snprintf to ensure boundary checking, or use dynamic memory allocation (e.g., gf_malloc) to accommodate paths of arbitrary length.

• Source: ⚠️ https://github.com/gpac/gpac/issues/3436
• User: peterx (UID 94522)
• Submission: 03/02/2026 09:35 (1 month ago)
• Moderation: 03/14/2026 23:01 (13 days later)
• Status: Accepted
• VulDB entry: 351091 [GPAC up to 2.5-DEV-rev2167-gcc9d617c0-master MP4Box swf_parse.c swf_def_bits_jpeg szName stack-based overflow]
• Points: 20