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

[Marton Balint]

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.

Regards,
Marton