[FFmpeg-devel] stsz overflow

Alex Converse alex.converse
Tue Aug 25 23:48:50 CEST 2009

On Tue, Aug 25, 2009 at 2:19 PM, Baptiste
Coudurier<baptiste.coudurier at gmail.com> wrote:
> On 8/25/2009 11:11 AM, Reimar D?ffinger wrote:
>> On Tue, Aug 25, 2009 at 10:16:52AM -0700, Frank Barchard wrote:
>>> On Tue, Aug 25, 2009 at 9:16 AM, Reimar D?ffinger
>>> <Reimar.Doeffinger at gmx.de>wrote:
>>>> On Tue, Aug 25, 2009 at 09:11:21AM -0700, Baptiste Coudurier wrote:
>>>>>> Wow, what a mess (IMO). I think we are already at the point where it
>>>>>> would be simpler to just get rid of that buffer and directly read the
>>>>>> values "one by one" from the file.
>>>>> No, it was decided to be done that way when the patch was submitted.
>>>> Obviously the review at that time did not take into account the
>>>> additional code and complexity of avoiding buffer overflows, which
>>>> unless someone comes up with a cleaner check is a really good reason
>>>> to reconsider that decision.
>>> Here is the simplest change that addresses the math overflow. ?It limits
>>> stsz to 134,217,728 entries.
> Looks reasonable.

For a 32-bit field size the actual limit on the number of entries is
(2^32-1-4-4-1-3-4-4)/4 = 1073741818 based on a 4 byte field specifying
atom size in bytes and subtracting off fixed headers. This generalises
to 16-bit field 2147483637, for an 8-bit field 4294967275, and for a
4-bit field it saturates to 4294967295. Is there anything else that
could impose an absolute ceiling on these values? Or are we not going
to worry about legal but insanely long sample sizes tables?

More information about the ffmpeg-devel mailing list