Fuzzing has discovered one crash bug so far. It's not related to my changes.
The crash has some potential to be exploitable so I've emailed ffmpeg-secur...@ffmpeg.org. Email includes a sample and repro instructions. On Sat, 9 Nov 2024 at 01:08, South East <8billion.peo...@gmail.com> wrote: > > On Sat, 9 Nov 2024 at 00:37, Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > > On Mon, Nov 04, 2024 at 06:14:07AM +0000, South East wrote: > > > Hi all - what do I need to do to progress this? > > > > iam a bit overloaded with work ATM, but bayer or interlacing combined with > > jpeg gives me memories of segfaults. So maybe you can run this through some > > fuzzer > > with some samples that trigger the code pathes > > to check it a bit > > Thanks. I have experience with AFL so this is practical for me. The > likely output is > a collection of samples that will improve code coverage, focussing on MLV and > DNG files. > > Does ffmpeg use AFL for testing already? I would expect to make local code > modifications to ffmpeg in order to improve speed of fuzzing (see e.g. > __AFL_LOOP). > Would you want those changes? It should be obvious they do something because > of improved code coverage, perhaps that is enough. > > I would expect testing with ffplay (with an ASAN enabled build) would be an > acceptable scope (there is no encoder for MLV). Is that assumption correct? > > I would guess we are only interested in new problems when the patches are > applied, i.e., if I discover old flaws, that shouldn't have any > bearing on whether > my patches are accepted. > > Beyond that, what would you consider evidence of adequate testing? _______________________________________________ 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".
