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

[Hendrik Leppkes]

On Tue, Mar 7, 2017 at 11:55 AM, Michał Krasowski <mkrasowski at opera.com> wrote:
> @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.
>
> 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?
> * 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?

The padding is 32 *bytes*, which is plenty for all optimized bitstream
readers we use.
Just make sure those extra bytes are zeroed to avoid any issues.

> * How to find such information without reading all bolts and nuts of ffmpeg
> source?
>

You don't need to read everything, but the main header would
definitely be benefifical.
Feel free to recommend changes to the documentation if you think
something crucial could be clearer (ideally right in patch form!)

- Hendrik