[FFmpeg-devel] [PATCH 1/3] Revert "avcodec: Add max_pixels options"

Nicolas George george at nsup.org
Mon Dec 12 13:04:05 EET 2016


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


More information about the ffmpeg-devel mailing list