[Ffmpeg-cvslog] r6733 - trunk/libavformat/mov.c

Baptiste Coudurier baptiste.coudurier
Fri Oct 20 10:43:58 CEST 2006


Michael Niedermayer wrote:
>>> [...]
>> Humm my bad, I misused memleak term, I wanted to illustrate that if
>> null_read_packet always return buf_size, s->read_read_packet will never
>> fail and eof_reached won't ever be set.
> true
>> Further get_buffer/get_byte wont never fail either,
> yes, unless theres somethig else wrong, but either way not a
> single get_buffer() call in mov.c checks the return value so i dont see
> how this would make a difference

I think difference is that we read from file, while here we read from

>> and further parsing
>> might read memory beyond. 
> i dont see how

Let's say, stts atom contains a wrong entry count, it will read process'
memory after the moov_data allocated, and nothing will stop. While
reading from file is not really harmful, I feel like more worried about
reading from memory.

>> Since it is 'moov' atom, supposedly containing
>> whole metadata, I was a bit afraid that would lead to a security risk,
>> but I guess I'm worrying too much.
> again i dont see how
> if you say there could be some infinite loop or so, yes maybe that could
> happen, though iam not sure how exactly but a security issue like writing
> over the end of a buffer, i cant see how my change can cause this

Not directly, and Im surely wrong being afraid.

> but iam perfectily fine with returning -1 on any but the first call to
> read_null_packet(), 
> one way to do this is to set opaque to the ByteIOContext and then
> if(opaque){
>     opaque->opaque=NULL; 
>     return buf_size;
> }else
>     return -1;
> [...]

I was thinking about something like that, or init_put_bytes with
read_packet as NULL, and internally use a null_read_packet(). That way,
you don't have to define a null_reading_packet each time you want to
read from memory.

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312

More information about the ffmpeg-cvslog mailing list