[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Mon Nov 14 23:05:06 EET 2016

On 14.11.2016 21:38, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Andreas Cadhalpun a écrit :
>> Consider the (not so) theoretical case of API users simply (and wrongly)
>> using the structs on the stack instead of dynamically allocating them.
>> With the internal pointer the internal struct gets allocated in the
>> respective init function and things mostly work fine, while with
>> your proposal this would cause out-of-bounds reads/writes, which
>> likely means an arbitrary code execution vulnerability.
> I think it will likely result in their application not working at all
> very soon, and therefore them realizing their mistake. This is exactly
> how I noticed that filfmts allocates the links itself.

It might work at first by accident and then some change in the internal
API could cause problems.
If the API usage is wrong, it should fail at build-time and not introduce
grave security vulnerabilities at run-time.

>> If you really care so much about this, you can make the struct completely
>> private and add getter/setter functions for those elements that need
>> public access.
> I would be ok with that. But that is a big incompatible API change. I
> could argue that lavfi's API is currently unusable anyway.

API changes in libavfilter are less of a problem, since not that many
programs use it. For example, the codecpar change has orders of magnitude
more impact.
However, ideally any incompatible API change should be coordinated with Libav.

Best regards,

More information about the ffmpeg-devel mailing list