Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit : > You misunderstand > > I want to find code that allocates too much memory where it should > not. > to give an example > there was long ago some code like > > len = read() > for (i<len) > x= alloc() > x.whatever =read() > ... > > Straight OOM here with a tiny input file. > add a simple if(eof) in there and no OOM anymore > this is just one example, code can look very diferent. > > I want to find these cases and i want to fix them > But what i get from the fuzzer is files with resolutions like > 65123x3210 which go OOM because of valid but silly resolution. > If i can limit the resolution then i can find the other issues > which i can fix. > If i cannot limit the resolution then i cannot fix the other issues > as they are in a sea of OOMs from large resolution files > > Nothing you can do at the OS level will get you this effect
Thanks for explaining. If I read this correctly, this option does not fix any security issue at all, it only help you find other parts of the code that may contain security issues. Am I right? > it is exceptionally unprofessional to publish testcases for CVEs > before they have been fixed. > Also more generally its the researchers choice/job to publish their > work. If you belive it should be put in a ticket you should ask him > not a 3rd party like me to do that. This is Free software, secrecy is not a good policy. "I have this patch that fix a bug, but I can not show you the bug." Well, if the patch is straightforward, we can accept it, but if the patch is not straightforward, we need, collectively, to see the bug. I can understand that if the bug is a critical 0-day exploit, some leeway must be accepted. But "there is a file that triggers a crash" is not enough by far. > who is "us", who is affected by this ? > I thought i would be maintaining this alone. Is there someone who > will help and work on this ? Maintaining "this": it does not work that way, a change in the code puts burden on anybody that work on the code, not just the person who wants the feature. -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
