[FFmpeg-devel] [PATCH 3/7] avcodec/alsdec: Fix integer overflow with buffer number

Thilo Borgmann thilo.borgmann at mail.de
Sat Jul 6 22:39:32 EEST 2019


Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
> 
> 
> On 21.06.2019, at 00:47, Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
>> Fixes: signed integer overflow: 65313 * 65313 cannot be represented in type 'int'
>> Fixes: 15290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5738074249625600
>>
>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>> ---
>> libavcodec/alsdec.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
>> index 79d22b7c2b..8e0d3e5f83 100644
>> --- a/libavcodec/alsdec.c
>> +++ b/libavcodec/alsdec.c
>> @@ -1990,6 +1990,8 @@ static av_cold int decode_init(AVCodecContext *avctx)
>>
>>     // allocate quantized parcor coefficient buffer
>>     num_buffers = sconf->mc_coding ? avctx->channels : 1;
>> +    if (num_buffers * (uint64_t)num_buffers > INT_MAX)
>> +        return AVERROR_INVALIDDATA;
> 
> It would be nice if it was clear which code this check protects, i.e. some connection between the check and the code that overflows.
> I guess one might also ask if > 30 000 channels might not be something to catch and disallow earlier and generally...

AFAICT the specs allow all 16 bit aka 65536 (+1) channels. For the case that remark from Raimar had been addressed..

The rest lgtm. I would appreciate s.o. bumping me if I miss something about ALS on devel, pls 0:-)

-Thilo





More information about the ffmpeg-devel mailing list