21-byte crafted .vpk file crashes FFmpeg apps via VPK demuxer divide-by-zero

What happened

A bug report on FFmpeg's official issue tracker, which rose to the front page of Hacker News, documents an integer division-by-zero in the demuxer that handles Sony PlayStation 2 VPK audio files. According to the report, a crafted 21-byte input crashes any application built on FFmpeg that opens a malicious .vpk file or stream. The reporter rates the severity medium: the bug is a dependable denial of service, not a stepping stone to code execution.

Where it goes wrong

The problem sits in libavformat/vpk.c, inside the vpk_read_packet function. When the demuxer reaches the final block of a stream, it calculates a block size and a skip value, and both calculations divide by the stream's channel count, par->ch_layout.nb_channels. If that count is zero, the CPU raises SIGFPE, an arithmetic exception, and the process dies on the spot.

The twist is that FFmpeg already validates this field. The header parser, vpk_read_header, rejects streams whose channel count is zero or negative. But the fuzzer that found the bug drives FFmpeg through a custom I/O layer, and according to the report, the data seen during probing and header parsing can diverge from the data read later. By the time packet reading starts, the channel count has reverted to zero, while the last-block size and block count were computed from earlier data that carried a valid channel layout. The existing check therefore never protects the packet-reading path.

The input and the trail

The crash file is 21 bytes long and opens with the VPK magic bytes, so format auto-detection routes it to the VPK demuxer as soon as an application calls avformat_open_input. A debugger shows the SIGFPE at vpk.c:89, with the stack running through ff_read_packet, read_frame_internal and av_read_frame, the standard reading API that virtually every FFmpeg consumer uses. No interaction beyond opening the file is required.

The reporter says the file plants a zero channel count at header offsets 0x0e through 0x11, though the hex dump included in the report does not visibly show zeros there, an oddity consistent with the header-versus-read divergence the report itself describes.

The bug was found by the reporter's own fuzzer, published on GitHub; the report's title calls the tool vibecoded, meaning it was built with heavy AI assistance. Surfacing the crash took roughly 495,000 executions, a corpus of about 13,000 entries and just under eleven hours of fuzzing.

Exploitability and proposed fix

The report's assessment is blunt: the crash is deterministic, the trigger is shallow, and there are no preconditions, since the input is self-contained. But it is also purely a crash. There is no out-of-bounds access, no use-after-free, no null dereference and no controlled write, so the practical impact is limited to service interruption.

The suggested fix is a guard at the top of vpk_read_packet that returns FFmpeg's standard invalid-data error when the channel count is zero, mirroring the validation already present in the header parser. The report also includes a regression test that feeds the 21-byte input to the demuxer and expects a clean error return rather than a signal. It does not state whether a patch has landed upstream yet.

Why it matters

FFmpeg sits inside countless media players, transcoders, thumbnail generators and cloud media pipelines, and any of them that open untrusted uploads through avformat_open_input are reachable with a 21-byte payload. The bug also illustrates a subtle failure mode in media parsing code: validating a field once at header time is not enough when later stages re-read from the same source, so derived values need to be treated as untrusted at the point of use. Finally, the fact that an AI-assisted side-project fuzzer turned up a real defect in one of the most heavily audited C codebases in existence says a great deal about how low the barrier to entry for security research has become.