← Our Research

ASI-2026-0009

tOS M4A Demuxer — Out-of-Bounds Read via Integer Underflow in first_chunk

HIGH FIXED CVSS: 7.1 Published: 2026-07-20

Summary

In the M4A demuxer of m4a_demux.c, the first_chunk field of an stsc box entry is read directly from an untrusted M4A/MP4 file with no validation that it is at least 1, as required by the ISO-BMFF specification. A crafted file setting first_chunk to 0 causes a subsequent chunk-1 computation to underflow to 0xFFFFFFFF, producing a wild out-of-bounds pointer read when locating a sample's offset in the stco/co64 chunk-offset table, and a further out-of-bounds read when copying sample data using that offset. This is reachable simply by playing an attacker-supplied .m4a or .mp4 file through the media player.

How We Found It

After finding the integer overflow in the PNG parser in ASI-2026-0004, we suspected similar arithmetic mistakes might exist elsewhere in the media demuxing/decoding code, and re-audited kernel/audio. While reviewing the stsc/stco sample-to-chunk resolution logic in m4a_demux.c, we found that the first_chunk field was never validated to be at least 1, as required by the ISO-BMFF specification.

Technical Detail

The first_chunk field of an stsc box entry is read directly from an untrusted M4A/MP4 file with no validation that it is at least 1. After locating which chunk a sample belongs to, the code computes chunk - 1 to index into the stco/co64 chunk-offset table. When first_chunk is 0, this unsigned subtraction underflows to 0xFFFFFFFF. This enormous, wrong index produces a wild out-of-bounds pointer read in the chunk-offset table; the resulting (meaningless) offset then causes a second out-of-bounds read when it's used to copy sample data.

Attack Scenario

An attacker crafts a .m4a or .mp4 file with the first_chunk field of an stsc box entry set to 0. When the victim attempts to play this file through the media player, the chunk - 1 computation underflows to 0xFFFFFFFF, causing a wild out-of-bounds read in the stco/co64 chunk-offset table and a further out-of-bounds read when the resulting invalid offset is used to copy sample data. Triggering this requires nothing more than attempting to play the malicious file.

Root Cause

first_chunk is read directly from the file's stsc box and used to compute chunk-1 as an index into the stco/co64 chunk-offset table without validating that it is >=1, allowing an unsigned integer underflow to produce a wild out-of-bounds offset.

Fix

The demuxer now rejects any stsc entry with first_chunk == 0 before it can be used in the chunk-offset computation.

Affected Platforms

Artfical tOS < 0.9.113

Weakness Type

CWE-191, CWE-125

Discovered By

Artfical DT Developer Talha Berk Arslan

References