[FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets
wm4
nfxjfg at googlemail.com
Wed Mar 8 20:35:50 EET 2017
On Wed, 8 Mar 2017 19:20:15 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote:
> > On Wed, 8 Mar 2017 17:11:12 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >
> > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote:
> > > > On Wed, 8 Mar 2017 15:36:25 +0100
> > > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > >
> > > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote:
> [...]
> > >
> > > >
> > > > > also it may be interresting to disable this check for fuzzing so
> > > > > side data can be fuzzed in a wider range of cases and any past
> > > > > testcases that happen to use this can still be used for regression
> > > > > testing
> > > >
> > > > I think what you want is fault injection for memory errors, seems out
> > > > of scope here.
> > >
> > > no, i want fuzzing to continue to fuzz side data, it did so in the
> > > past and it should continue to do so.
> >
> > You can fuzz side data as much as you can fuzz AVFrame or
> > AVCodecContext. I believe randomly changing in-memory data structures
> > is referred to as fault injection, not fuzzing.
>
> it doesnt really matter what you call it, but it was done and the
> patch breaks it if theres no option to disable it or something else
PS: honestly, I think you're trolling with this. The possibility that
random packets could be interpreted as side-data doesn't look like
something that was accounted for, and I highly doubt this plays a role
for fuzzing (or ever occurred in a fuzzing case). Why are you so
hell-bent in finally preventing this arguably dangerous corner case? It
makes no sense at all. Explain yourself.
More information about the ffmpeg-devel
mailing list