[FFmpeg-devel] [PATCH] avcodec/msp2dec: Check available space in RLE decoder

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Michael Niedermayer:
>> Fixes: out of array read
>> Fixes: 32968/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSP2_fuzzer-5315296027082752
>>
>> 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/msp2dec.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/msp2dec.c b/libavcodec/msp2dec.c
>> index cc548d218a..87057fb5e2 100644
>> --- a/libavcodec/msp2dec.c
>> +++ b/libavcodec/msp2dec.c
>> @@ -68,9 +68,10 @@ static int msp2_decode_frame(AVCodecContext *avctx,
>>  
>>          bytestream2_init(&gb, buf, pkt_size);
>>          x = 0;
>> -        while (bytestream2_get_bytes_left(&gb) && x < width) {
>> +        while (bytestream2_get_bytes_left(&gb) > 0 && x < width) {
> 
> This decoder uses the checked bytestream2 API, so != 0 and > 0 should be
> equivalent for bytestream2_get_bytes_left(&gb).
> 
>>              int size = bytestream2_get_byte(&gb);
>>              if (size) {
>> +                size = FFMIN(size, bytestream2_get_bytes_left(&gb));
>>                  memcpy(p->data[0] + y * p->linesize[0] + x, gb.buffer, FFMIN(size, width - x));
> 
> width can include seven bytes of the packet's padding, but it stays
> within the padding, so I wonder where the out of array read comes from.
> The only fishy thing in this decoder I see is that 2 * avctx->height
> might overflow.
> 

Correction: width has no relationship with the packet's size at all; the
width - x in the above FFMIN only ensures that it writes at most seven
bytes into the frame's padding (is the frame actually guaranteed to be
padded?).
Btw: I don't see any advantage of writing in the frame's padding.

- Andreas