[FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

[Michael Niedermayer]

On Fri, Dec 09, 2016 at 08:33:29PM +0100, Marton Balint wrote:
> 
> On Fri, 9 Dec 2016, Michael Niedermayer wrote:
> 
> >On Thu, Dec 08, 2016 at 09:47:53PM +0100, Nicolas George wrote:
> >>L'octidi 18 frimaire, an CCXXV, Michael Niedermayer a écrit :
> >>>A. Is a heap limit for av_*alloc*() acceptable ?
> >>>B. Are case based limits acceptable ?
> >>
> >>No. This is the task of the operating system.
> >>
> >
> >>>also even if C is choosen, a small set of limits on the main parameters
> >>>still is needed to allow efficient fuzzing, all issues reported
> >>>by oss-fuzz recently are "hangs" due to slow decoding,
> >>
> >>Then set a limit at the operating system level.
> >
> >You are misunderstanding the problem i think
> >
> >The goal of a fuzzer is to find bugs, crashes, undefined, bad things,
> >OOM, hangs.
> >
> >If the code under test can allocate arbitrary amounts of memory and
> >take arbitrary amounts of time in a significant number of non-bug
> >cases then the fuzzer cannot reliably find the corresponding bugs.
> >
> >moving the threshold of where to declare something OOM or hang around
> >will not solve this.
> >blocking high resolution, high channel count, high stream count
> >cases OTOH should improve the rate of false positives.
> 
> Then you should run the fuzzer with the limits you find optimal, no?
> 
> Reducing the defaults which causes rare-but-existing files to stop
> working does not make much sense to me. I particularly don't like
> the stream count limits, because parsing possibly corrupted sources
> (e.g. mpegts) can easily generate a high number of mostly harmless
> empty streams as far as I remember.
> 
> It just might make more sense to create a section in the
> documentation or a wiki page which describes that if you are working
> with untrusted files, you should use a sandbox, use system resource
> limits, and you might use these options as well.
> 

> If we still want a default limit, that limit should be IMHO
> _insanely_ high, tens of thousands, not hundreds.

The OOM case that ive debuged was in the tens of thousands so
a limit in that range will likely not stop much

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20161209/21b24f17/attachment.sig>