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

[Michael Niedermayer]

On Sun, Dec 11, 2016 at 05:47:34PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > we need these limit paramters for fuzzing to be practical.
> 
> Maybe, but we can take a few days to do it properly instead of rushing a
> badly-designed "fix" that does not fix anything and then being forced
> into a maintenance nightmare because of it.
> 

> First step: these commits and options must go away immediately;

Well, we need these options for efficient fuzzing


> 
> Second step: you show us exactly what problem you are trying to solve.

There are multiple independant things these options solve
I belive i explained all already, but

Fuzzers search and find issues like out of array accesses but also
hangs and oom conditions.
Fuzzers find hangs and OOM conditions by executing code until it runs
out of memory or reaches a timeout.
These cases are then reported and need to be checked by a human (that
being me in practice it seems)
ATM almost all of reported issues are false positives, going through
them takes significant amounts of time. the max_pixels parameter should
fix this as all the cases i looked at where hitting out of memory or
timeout because of very high resolutions.

The 2nd issue this fixes is a CVE that was reported about a crafted
file with i belive 26k streams hitting OOM.
If you belive this CVE is invalid and not a security issue iam totally
the wrong to discuss that with. But i like to fix issues instead of
arguing about why they are or are not a security issue.

The 3rd is that as a user i like to be able to set limits on pixels
and streams to limit resource use and avoid crashes

The 4th is that it seems to me everyone else on oss-fuzz can avoid
this issue, why is something so basic so hard on ffmpeg-devel ?

It is very likely there are more problems this fixes
maybe a browser loading a image that it knows should be 256x256 ?
i dont know, but why shouldnt the user be able to limit the number
of pixels?



> 
> Third step: we discuss and implement a proper solution.

I already did that and the previously applied solution is the result.
If you (singular or plural) dislike how its done, noone stops you from
proposing and implementing a better solution.

as said, from my point of view the solution is what is needed. and
ive spend many times the time on this (mostly discussions) that i
would have wanted to.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161211/661bd18b/attachment.sig>