Alex Converse <alex.conve...@gmail.com> writes: > On Thu, Sep 8, 2011 at 4:05 PM, Laurent Aimar <fen...@elivagar.org> wrote: >> Hi, >> >> After trying some fuzzing on libavcodec, it seems that a lot of decoders >> does not check (or not enough) for buffer overread which can lead for some >> to a segfault. >> >> I attached a patch that make get_bits.h function checked for overread by >> default but let safe decoders disabling the checks at compilation time by >> defining UNCHECK_BITSTREAM_READER before including get_bits.h. >> If such patch would be including, I would gladly provide a patch >> adding the #define UNCHECK_BITSTREAM_READER to the decoder that are 'safe'. >> >> I haven't yet benchmark the performance loss but will do so. >> >> One decoder breaks with this patch: mpegaudio. It seems to do weird things >> with two get bit context and switching them while decoding. I will try to >> have a look at it (unless someone would volunteer to explain me what it is >> doing :) >> >> Also, I haven't implemented the checks for A32_BITSTREAM_READER. But I am not >> sure when (or even if) this reader is used. >> >> Regards, >> > > I've put this in a separate post because this is probably the more > contentious part... > > I think this should be opt-in instead of opt-out. i.e. the bad > decoders (even if that is most of them) should have the ugly boiler > plate, not the good ones. > > And in previous discussions the prevailing opinion has been that on > decoders for more modern formats, that make a good attempt to respect > buffer sizes, not to opt them into something like this even if they > are not perfect and instead the individual flaws have been fixed. > > This is a very expensive form of error resilience and there are a lot > of use cases where people just don't care. They will tolerate the SEGV > on the occasional bad file if it means they can decode a good with > reasonable speed. > > i.e. Please turn this feature on for the Indeos and the Sorensons and > the like, but let's fix the individual bugs in the H.264s and VP8s. > Turning this on for them is overkill.
Agree. This will annihilate performance, so if we're going to do this, we might as well stop altogether. -- Måns Rullgård m...@mansr.com _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
