FFmpeg Vulnerability: Division by Zero Bug Found in VPK Demuxer

Integer Divide-by-Zero in vpk_read_packet (VPK Demuxer) #24290

opened 18 hours ago by [Darío Clavijo]

· 1 comment

Hello.

This is a bug found with our fuzzer: https://github.com/daedalus/fuzzer/

File: libavformat/vpk.c:89

Severity: Medium — crafted 21-byte input crashes any FFmpeg-based application that opens a malicious .vpk file or stream

Root cause: vpk_read_packet divides vpk->last_block_size by par->ch_layout.nb_channels without checking whether nb_channels is zero. A malformed VPK header can set nb_channels = 0, causing SIGFPE on the division.

Description

The Sony PS2 VPK demuxer (libavformat/vpk.c) reads audio blocks from a custom container format. In vpk_read_packet, the last block of the stream is handled specially:

if (vpk->current_block == vpk->block_count) {
 unsigned size = vpk->last_block_size / par->ch_layout.nb_channels;
 unsigned skip = (par->block_align - vpk->last_block_size)
 / par->ch_layout.nb_channels;
 ...
}

Both size and skip divide by par->ch_layout.nb_channels. When nb_channels is zero, the CPU raises SIGFPE (integer divide-by-zero exception).

Trigger Chain

1. Demuxer probe (vpk_probe) matches the VPK big-endian magic and assigns the input to the VPK demuxer.
2. vpk_read_header parses the 24-byte header. The fuzz input sets nb_channels = 0 at header bytes 0x0e–0x11. vpk_read_header does validate nb_channels > 0, but in the fuzzer's custom-AVIO path the probe/header data and the later packet-read data can diverge: by the time vpk_read_packet runs, par->ch_layout.nb_channels has reverted to 0 from the original fuzz stream while vpk->last_block_size and vpk->block_count were computed from probe data with a valid channel count. The division is therefore reached with a live-but-zero divisor.
3. vpk_read_packet reaches the final-block branch and divides by zero on both size and skip.

Crash Input

Hex dump of the 21-byte crash input (crash_1787378545_34bc062c_sig_signal8.bin):

00000000 20 4b 50 56 56 50 00 f8 04 00 3b 03 61 39 56 32 | KPVVP....;.a9V2|
00000010 36 36 30 38 50 |6608P|

• Bytes 0–3: 20 4b 50 56 — ASCII `