diff mbox

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

Message ID 20190620224721.8480-3-michael@niedermayer.cc
State New
Headers show

Commit Message

Michael Niedermayer June 20, 2019, 10:47 p.m. UTC 
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@niedermayer.cc>
---
 libavcodec/alsdec.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Reimar Döffinger June 21, 2019, 7 a.m. UTC | #1 
On 21.06.2019, at 00:47, Michael Niedermayer <michael@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@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...
Thilo Borgmann July 6, 2019, 7:39 p.m. UTC | #2 
Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
> 
> 
> On 21.06.2019, at 00:47, Michael Niedermayer <michael@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@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
Michael Niedermayer July 6, 2019, 8:10 p.m. UTC | #3 
On Sat, Jul 06, 2019 at 09:39:32PM +0200, Thilo Borgmann wrote:
> Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
> > 
> > 
> > On 21.06.2019, at 00:47, Michael Niedermayer <michael@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@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..

its the chan_data_buffer allocation. Ill add a comment


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

not sure i understand the abbreviation but i will apply the patchset as it
seems, thats the consensus and ill try to ping you in the future of als patches unless
i forget ... sadly i tend to forget these things ...

Thanks

[...]
Thilo Borgmann July 6, 2019, 8:58 p.m. UTC | #4 
Am 06.07.19 um 22:10 schrieb Michael Niedermayer:
> On Sat, Jul 06, 2019 at 09:39:32PM +0200, Thilo Borgmann wrote:
>> Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
>>>
>>>
>>> On 21.06.2019, at 00:47, Michael Niedermayer <michael@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@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..
> 
> its the chan_data_buffer allocation. Ill add a comment
> 
> 
>>
>> The rest lgtm. I would appreciate s.o. bumping me if I miss something about ALS on devel, pls 0:-)
> 
> not sure i understand the abbreviation but i will apply the patchset as it
> seems, thats the consensus and ill try to ping you in the future of als patches unless
> i forget ... sadly i tend to forget these things ...

"Someone".

Do apply. The rest is just in regard of redundance, I'll not miss every patch ^^

Thanks,
Thilo
diff mbox

Patch

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;
 
     ctx->quant_cof        = av_malloc_array(num_buffers, sizeof(*ctx->quant_cof));
     ctx->lpc_cof          = av_malloc_array(num_buffers, sizeof(*ctx->lpc_cof));