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. If this isn't the case anymore I'm wondering what has changed? Is there a proposed initial opt-out list? _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
