On Tue, Feb 9, 2016 at 5:45 PM, Luca Barbato <lu_z...@gentoo.org> wrote:
> On 09/02/16 23:23, Vittorio Giovara wrote:
>> From: Michael Niedermayer <michae...@gmx.at>
>>
>> Fixes call stack overflow
>> Fixes: case1_call_stack_overflow.mp4
>> Found-by: Michal Zalewski <lcam...@coredump.cx>
>> Signed-off-by: Michael Niedermayer <michae...@gmx.at>
>> ---
>> libavformat/isom.h | 1 +
>> libavformat/mov.c | 13 ++++++++++++-
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>> index f8e398b..b4f0202 100644
>> --- a/libavformat/isom.h
>> +++ b/libavformat/isom.h
>> @@ -190,6 +190,7 @@ typedef struct MOVContext {
>> int has_looked_for_mfra;
>> MOVFragmentIndex** fragment_index_data;
>> unsigned fragment_index_count;
>> + int atom_depth;
>> } MOVContext;
>>
>> int ff_mp4_read_descr_len(AVIOContext *pb);
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 8bfe974..be2728c 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -3412,6 +3412,12 @@ static int mov_read_default(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>> MOVAtom a;
>> int i;
>>
>> + if (c->atom_depth > 10) {
>> + av_log(c->fc, AV_LOG_ERROR, "Atoms too deeply nested\n");
>> + return AVERROR_INVALIDDATA;
>> + }
>
> why 10? Is it the nesting limit specified somehow?
>
> I'm not against the general idea, but I'm not so keen in having possibly
> valid/borderline files unreadable just because something got nested 11
> level deep.
So what is the definite idea for this patch?
--
Vittorio
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
