VYPR
← All advisories
Low severity3.3NVD Advisory· Published May 26, 2026· Updated May 26, 2026

CVE-2026-9572

CVE-2026-9572

Description

A security vulnerability has been detected in GPAC up to 2.4.0. Affected by this issue is the function Media_GetSample of the file src/isomedia/media.c of the component MP4Box. Such manipulation of the argument cat leads to memory leak. The attack can only be performed from a local environment. The exploit has been disclosed publicly and may be used. The name of the patch is e79c5cbe8b3fed27f4854ec229457d30c96206f1. It is best practice to apply a patch to resolve this issue.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

GPAC MP4Box MP4Box -cat command on a malformed MP4 file triggers a memory leak in Media_GetSample() due to missing buffer release when handling malformed tracks.

Vulnerability

The vulnerability resides in GPAC up to version 2.4.0, specifically in the Media_GetSample function within src/isomedia/media.c. When MP4Box processes a malformed MP4 file with the -cat argument, it may encounter tracks without sample tables or sample description boxes, or unsupported hint tracks. During concatenation, when such malformed tracks are removed and new destination tracks are created, a sample buffer allocated in Media_GetSample() is not released, leading to a memory leak [1][2]. The fix is commit e79c5cbe8b3fed27f4854ec229457d30c96206f1 [3].

Exploitation

An attacker must have local access to the system to provide a specially crafted malformed MP4 file. The attack is performed by running the MP4Box -cat command on that file, which triggers the memory leak in Media_GetSample() when the function attempts to allocate a buffer for a sample with zero data_size [2]. No authentication or user interaction beyond executing the command is needed.

Impact

Successful exploitation results in a memory leak, which could gradually exhaust available memory, leading to denial of service for the application or system. The leak is limited to the memory allocated per vulnerable operation; repeated processing of malformed files could amplify the impact. There is no information disclosure, privilege escalation, or code execution [1][2].

Mitigation

The patch for this issue is available in commit e79c5cbe8b3fed27f4854ec229457d30c96206f1, which prevents allocation of zero-size memory blocks in Media_GetSample() [3]. Users should update GPAC to a version containing this patch. As a best practice, avoid processing untrusted MP4 files with MP4Box -cat on unpatched versions [1][2].

References
  1. GitHub - gpac/gpac: GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery
  2. LeakSanitizer: memory leak in `Media_GetSample()` when using `MP4Box -cat` on malformed MP4
  3. fuzz: prevent UB malloc(0) in Media_GetSample() (fixes #3557) · gpac/gpac@e79c5cb

AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Gpac/Gpacreferences2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)range: <=2.4.0

Patches

1
e79c5cbe8b3f

fuzz: prevent UB malloc(0) in Media_GetSample() (fixes #3557)

https://github.com/gpac/gpacAurelien DavidMay 5, 2026via nvd-ref
commit
1 file changed · +8 −3
  • src/isomedia/media.c+8 −3 modified
    @@ -623,14 +623,19 @@ GF_Err Media_GetSample(GF_MediaBox *mdia, u32 sampleNumber, GF_ISOSample **samp,
 		if (! (*samp)->data)
 			(*samp)->alloc_size = 0;
 
+
+		size_t size_to_alloc = data_size + mdia->mediaTrack->padding_bytes;
+		if (!size_to_alloc)
+			return GF_IO_ERR;
+
 		/*and finally get the data, include padding if needed*/
 		if (ext_realloc) {
-			(*samp)->data = mdia->mediaTrack->sample_alloc_cbk(data_size + mdia->mediaTrack->padding_bytes, mdia->mediaTrack->sample_alloc_udta);
+			(*samp)->data = mdia->mediaTrack->sample_alloc_cbk(size_to_alloc, mdia->mediaTrack->sample_alloc_udta);
 		} else if ((*samp)->alloc_size) {
-			(*samp)->data = (char *) gf_realloc((*samp)->data, sizeof(char) * ( data_size + mdia->mediaTrack->padding_bytes) );
+			(*samp)->data = (char *) gf_realloc((*samp)->data, size_to_alloc );
 			if ((*samp)->data) (*samp)->alloc_size = data_size + mdia->mediaTrack->padding_bytes;
 		} else {
-			(*samp)->data = (u8 *) gf_malloc(data_size + mdia->mediaTrack->padding_bytes);
+			(*samp)->data = (u8 *) gf_malloc(size_to_alloc);
 		}
 		if (! (*samp)->data) return GF_OUT_OF_MEM;

Vulnerability mechanics

Root cause

"Missing zero-size check before memory allocation in Media_GetSample() allows malloc(0) when data_size and padding_bytes sum to zero."

Attack vector

An attacker with local access provides a malformed MP4 file that, when processed by `MP4Box -cat`, causes `data_size + mdia->mediaTrack->padding_bytes` to evaluate to zero [patch_id=2568241]. This results in a `malloc(0)` call, which is undefined behavior and, under AddressSanitizer, manifests as a memory leak [ref_id=1]. The attack requires only local file access and low privileges (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L). The malformed input contains tracks without sample tables, tracks without sample description boxes, and unsupported hint tracks that are removed during concatenation, but the sample buffer allocated in `Media_GetSample()` is not released on this path [ref_id=1].

Affected code

The vulnerability resides in `Media_GetSample()` in `src/isomedia/media.c` [patch_id=2568241]. The function is called during MP4Box `-cat` operations when importing or concatenating tracks from a malformed MP4 file [ref_id=1]. The call chain is `gf_isom_get_sample_ex` → `gf_isom_get_sample` → `gf_import_isomedia_track` → `gf_import_isomedia` → `gf_media_import` → `import_file` → `cat_isomedia_file` [ref_id=1].

What the fix does

The patch introduces a local variable `size_to_alloc` that computes `data_size + mdia->mediaTrack->padding_bytes` and adds an early return with `GF_IO_ERR` if `size_to_alloc` is zero [patch_id=2568241]. This prevents the undefined behavior of calling `malloc(0)`, `realloc(0)`, or the custom `sample_alloc_cbk` with a zero size. The three allocation paths (custom callback, realloc, and malloc) are all updated to use the pre-checked `size_to_alloc` instead of recomputing the expression [patch_id=2568241]. The commit message confirms this fixes issue #3557 and prevents UB from `malloc(0)` [ref_id=2].

Preconditions

  • networkAttacker must have local access to the system
  • inputAttacker must provide a malformed MP4 file that triggers zero-size allocation in Media_GetSample()
  • inputVictim must run MP4Box -cat with the malformed file as input

Reproduction

1. Obtain the malformed MP4 PoC file from the linked issue (poc.zip) [ref_id=1]. 2. Run: `./bin/gcc/MP4Box -cat ./malformed.mp4 ./white.mp4 -out /dev/null` [ref_id=1]. 3. Observe the LeakSanitizer output showing a 1-byte direct leak allocated at `Media_GetSample` line 633 [ref_id=1].

Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

5

News mentions

0

No linked articles in our index yet.