A bug has been identified in FFmpeg using a fuzzer tool developed by Daedalus. The issue occurs in the file libavformat/vpk.c at line 89, with a severity rating of medium. A crafted 21-byte input can cause any FFmpeg-based application that opens a malicious .vpk file or stream to crash. The root cause is that the function vpk_read_packet divides vpk->last_block_size by par->ch_layout.nb_channels without verifying if nb_channels is zero. A malformed VPK header can set nb_channels to zero, leading to a SIGFPE (signal floating-point exception) during the division.
The Sony PS2 VPK demuxer, located in libavformat/vpk.c, processes audio blocks from a custom container format. In the function vpk_read_packet, the last block of the stream is treated differently, where both size and skip operations depend on par->ch_layout.nb_channels. When nb_channels is zero, the CPU triggers a SIGFPE due to the integer divide-by-zero exception.
The input that causes the crash has been documented in a hex dump (crash_1787378545_34bc062c_sig_signal8.bin). This divide-by-zero condition represents a denial-of-service vulnerability. There is no controlled write or arbitrary read adjacent to the faulting instruction, and the input can be embedded in a .vpk file or a container that identifies itself as VPK to trigger the crash in any application linked to FFmpeg.
To mitigate this issue, it is recommended to add a guard at the beginning of vpk_read_packet to reject zero-channel streams cleanly. This aligns with the existing validation in vpk_read_header, which returns AVERROR_INVALIDDATA when the number of channels is less than or equal to zero, thus preventing the SIGFPE error.
This issue appears to be similar to one previously discussed in the FFmpeg developer mailing list.