[FFmpeg-devel] [PATCH] Fix off-by-few crasher in ff_h2645_extract_rbsp function

Michał Krasowski mkrasowski at opera.com
Tue Mar 7 13:30:57 EET 2017


>> This email may contain Opera confidential information
>
>Please remove this, Carl Eugen
Ah, yes, default footer, sorry.

>> There are few things that are still not clear to me:
>> * Why is the 32 bit padding used when the doc says that
>>   64 bit offset may also be needed?
>
>I don't understand your question but you may want to
>send an update for this sentence.

I mean that the doc says:
> * This is mainly needed because some optimized bitstream readers read
> * 32 or 64 bit at once and could read over the end.<br>
So in case of reading 64 bits at once, may it be the case that 8 bytes padding
is needed?

On Tue, Mar 7, 2017 at 12:18 PM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
> 2017-03-07 11:55 GMT+01:00 Michał Krasowski <mkrasowski at opera.com>:
> > @Michael Niedermayer
> > I have read the documentation, namely
> >
> > /**
> >  * @ingroup lavc_decoding
> >  * Required number of additionally allocated bytes at the end of the input
> > bitstream for decoding.
> >  * This is mainly needed because some optimized bitstream readers read
> >  * 32 or 64 bit at once and could read over the end.<br>
> >  * Note: If the first 23 bits of the additional bytes are not 0, then
> > damaged
> >  * MPEG bitstreams could cause overread and segfault.
> >  */
> > #define AV_INPUT_BUFFER_PADDING_SIZE 32
> >
> > and now it seems to me that you prefer speed (a.k.a. optimization)
> > over having a self-contained functions.
>
> Luckily:
> Video players would be unusable without optimizations.
>
> > There are few things that are still not clear to me:
> > * Why is the 32 bit padding used when the doc says that
> >   64 bit offset may also be needed?
>
> I don't understand your question but you may want to
> send an update for this sentence.
>
> > * Even if I extend my data buffer
> >   to have those 4 bytes more, is there a risk that some functions
> >   in ffmpeg will read out-of-bounds?
>
> Definitely: Bugs are possible.
>
> [...]
>
> > This email may contain Opera confidential information
>
> Please remove this, Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


More information about the ffmpeg-devel mailing list