On Tue, May 21, 2019 at 08:38:02PM +0200, Reimar Döffinger wrote: > On Tue, May 21, 2019 at 11:15:03AM -0300, James Almer wrote: > > > I have a feeling this loop should have a stop condition like v < > > > SOME_LARGE_VALUE, say INT_MAX-255 or yuv_macroblock_count, to reject > > > corrupt/malicious files and not cause undefined behavior > > > > Using get_bits_left(gb) would be better than an arbitrary large value. > > It seems the original comment wasn't preserved, but get_bits_left > is fairly pointless because the 0-padding will cause loop exit > anyway. > Also get_bits_left wouldn't address the point that a 2GB input frame > of all-1s from the right position would here end up reading 2GB > 9 bits at a time. > Overflow by my calculations would only happen after > 500 GB, > so not sure that's a worry. > But depending on the contexts in which this function is used, > there might be obvious limits for v, in which case an early > exit would make sense (even when not, runs > 250 bytes can > likely safely assumed broken).
x/y macroblock counts are limited 8-bit, so yuv_macroblock_count never exceeds (255 * 255 * 3/2 = 97537). i this kind of check will suffice and speed up fuzzing tests. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
