[FFmpeg-devel] [PATCH] Fix off-by-few crasher in ff_h2645_extract_rbsp function
Michael Niedermayer
michael at niedermayer.cc
Tue Mar 7 13:21:36 EET 2017
On Tue, Mar 07, 2017 at 11:55:23AM +0100, MichaĆ Krasowski 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?
> * How to find such information without reading all bolts and nuts of ffmpeg
> source?
Where did you look?
Or said differently where would adding a pointer have helped you to
find this sooner ?
A patch adding such a pointer there is very likely welcome
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170307/3f2e715f/attachment.sig>
More information about the ffmpeg-devel
mailing list