On Fri, May 17, 2013 at 06:40:55PM +0200, Luca Barbato wrote: > 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.
If you like. It's an improvement anyway. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
