On Thu, Oct 08, 2020 at 07:57:56PM +0200, Andreas Rheinhardt wrote: > Commit bbc0d0c1fe2b7ecdc4367295594f084f85ad22f5 made the mjpeg decoder > use default Huffman tables when none are given, yet when initializing > the default Huffman tables, it did not use the correct number of entries > of the arrays used to initialize the tables, but instead it used the > biggest entry + 1 (as if it were a continuous array 0..biggest entry). > This worked because the ff_init_vlc_sparse() (and its predecessors) > always skipped entries with a length of zero and the length of the > corresponding elements was always initialized to zero with only the > sizes of the actually existing elements being set to a size > 0 lateron. > > Yet since commit 1249698e1b424cff8e77e6a83cfdbc9d11e01aa7 this is no > longer so, as build_vlc() actually read the array containing the values > itself. This implies that the wrong length now leads to a read beyond > the end of the given array; this could lead to crashs (but usually > doesn't); it is detectable by ASAN* and this commit fixes it. > > *: AddressSanitizer: global-buffer-overflow on address xy > ... > xy is located 0 bytes to the right of global variable > 'avpriv_mjpeg_val_ac_luminance' > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> > --- > Hard to believe that this wrong number has not been found earlier. > The code in question has been touched by about a dozen commits. >
Patchset LGTM _______________________________________________ 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".
