[FFmpeg-devel] [PATCH] avcodec/options_table: remove extradata_size from the AVOptions table

[Lukasz Marek]

On 9 March 2015 at 14:28, Michael Niedermayer <michaelni at gmx.at> wrote:

> On Mon, Mar 09, 2015 at 01:27:58PM +0100, Lukasz Marek wrote:
> > On 9 March 2015 at 12:19, Andreas Cadhalpun <
> > andreas.cadhalpun at googlemail.com> wrote:
> >
> > > On 09.03.2015 03:42, Michael Niedermayer wrote:
> > >
> > >> allowing access to the size but not the extradata itself is not useful
> > >> and could lead to potential problems if writing happens through this
> field
> > >>
> > >> Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > >> ---
> > >>   libavcodec/options_table.h |    1 -
> > >>   1 file changed, 1 deletion(-)
> > >>
> > >> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> > >> index 442b212..a906864 100644
> > >> --- a/libavcodec/options_table.h
> > >> +++ b/libavcodec/options_table.h
> > >> @@ -103,7 +103,6 @@ static const AVOption avcodec_options[] = {
> > >>   {"hex", "hex motion estimation", 0, AV_OPT_TYPE_CONST, {.i64 =
> ME_HEX
> > >> }, INT_MIN, INT_MAX, V|E, "me_method" },
> > >>   {"umh", "umh motion estimation", 0, AV_OPT_TYPE_CONST, {.i64 =
> ME_UMH
> > >> }, INT_MIN, INT_MAX, V|E, "me_method" },
> > >>   {"iter", "iter motion estimation", 0, AV_OPT_TYPE_CONST, {.i64 =
> > >> ME_ITER }, INT_MIN, INT_MAX, V|E, "me_method" },
> > >> -{"extradata_size", NULL, OFFSET(extradata_size), AV_OPT_TYPE_INT,
> {.i64
> > >> = DEFAULT }, INT_MIN, INT_MAX},
> > >>   {"time_base", NULL, OFFSET(time_base), AV_OPT_TYPE_RATIONAL, {.dbl =
> > >> 0}, INT_MIN, INT_MAX},
> > >>   {"g", "set the group of picture (GOP) size", OFFSET(gop_size),
> > >> AV_OPT_TYPE_INT, {.i64 = 12 }, INT_MIN, INT_MAX, V|E},
> > >>   {"ar", "set audio sampling rate (in Hz)", OFFSET(sample_rate),
> > >> AV_OPT_TYPE_INT, {.i64 = DEFAULT }, 0, INT_MAX, A|D|E},
> > >>
> > >>
> > > This looks very good, because it also fixes the ffm muxer to never
> create
> > > files with extradata_size setting, but without extradata.
> > >
> >
> > Isn't it API break? Maybe it is better to have a look on asv1 or ffm
> muxer
> > to fix problem itself, not to cover it.
> > I can have a look on this today's evening.
>
> you miss the problem, this is a demuxer side problem,
> a attacker can at least crash your application no muxer side change
> can fix this, the attacker has his own self written muxer that
> produces a mallicious bitstream
>
> of course you are correct that there is possibly also a problem on the
> muxer side and that this too should be fixed but that is less
> important.
>

OK.
I checked this issue and your patch fixes the issue so if you are OK with
removing this option I have no more remarks.