On 05/17/2013 06:10 PM, Kostya Shishkov wrote:
> On Fri, May 17, 2013 at 05:35:35PM +0200, Luca Barbato wrote:
>> Prevent out of buffer write when decoding broken samples.
>>
>> Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
>> CC: [email protected]
>> ---
>>  libavcodec/mjpegdec.c | 5 +++++
>>  libavcodec/mjpegdec.h | 7 ++++---
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
>> index 896fa99..7a1075d 100644
>> --- a/libavcodec/mjpegdec.c
>> +++ b/libavcodec/mjpegdec.c
>> @@ -941,6 +941,11 @@ static int 
>> mjpeg_decode_scan_progressive_ac(MJpegDecodeContext *s, int ss,
>>      int16_t *quant_matrix = s->quant_matrixes[s->quant_index[c]];
>>      GetBitContext mb_bitmask_gb;
>>  
>> +    if (ss < 0  || ss >= DCTSIZE2 ||
>> +        se < se || se >= DCTSIZE2 ||
>            ss somewhere?

Indeed, thanks for spotting the typo

> 
>> +        Ah < 0  || Al < 0)
>> +        return AVERROR_INVALIDDATA;
>> +
>>      if (mb_bitmask)
>>          init_get_bits(&mb_bitmask_gb, mb_bitmask, s->mb_width * 
>> s->mb_height);
>>  
> 
> Introducing DCTSIZE2 is unrelated and constant 64 is bloody obvious to anyone
> who knows a thing about JPEG.

Most of those security bugs are *obvious* for those that read the
specification of each of those protocols, formats and codecs.

I prefer underling once too many the glaring obvious.

I can split the 64 -> DCTSIZE2 rename in a second patch, but I'd rather
keep it.

lu



_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to