[FFmpeg-devel] [PATCH 5/7] ffmpeg: dynamically allocate stream_maps
Thu Aug 19 15:26:47 CEST 2010
On Wed, Aug 18, 2010 at 10:57:41PM +0200, Michael Niedermayer wrote:
> On Fri, Aug 13, 2010 at 08:24:18PM +0200, Aur?lien Jacobs wrote:
> > From: Aurelien Jacobs <aurel at gnuage.org>
> > ---
> > ffmpeg.c | 8 +++++---
> > 1 files changed, 5 insertions(+), 3 deletions(-)
> > diff --git a/ffmpeg.c b/ffmpeg.c
> > index dcaaecf..9e55f01 100644
> > --- a/ffmpeg.c
> > +++ b/ffmpeg.c
> > @@ -117,8 +117,8 @@ static AVCodec **output_codecs = NULL;
> > static int nb_output_files = 0;
> > static int nb_output_codecs = 0;
> > -static AVStreamMap stream_maps[MAX_FILES*MAX_STREAMS];
> > -static int nb_stream_maps;
> > +static AVStreamMap *stream_maps = NULL;
> > +static int nb_stream_maps = 0;
It is actually used. Hidden behind the GROW_ARRAY() macro :-(
So yes, I understand why you don't like such kind of macro...
> also are you sure that this and the other patches arent full of exploitable
> previously the arrays where as large as any access could be because there
> was a global hard limit ...
> have you checked that all accesses to the arrays are safe?
Yes, I've checked all accesses.
First of all, all those arrays are written only in parse_options() and
in a second time, they are only read in transcode().
The streamid_map array is an exception to this rule, but I've also
carefully checked all it access.
Each write to those arrays are preceded by a grow_array() call, to make
sure the array is big enough, and each read is either bounded by an
already existing check or by a check that I added.
So I'm confident that those patches are not full of exploitable bugs.
More information about the ffmpeg-devel