[Ffmpeg-cvslog] r6733 - trunk/libavformat/mov.c
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.
>> 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
> one way to do this is to set opaque to the ByteIOContext and then
> return buf_size;
> 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