@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? On Mon, Mar 6, 2017 at 8:53 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Mon, Mar 06, 2017 at 03:51:51PM +0100, Michał Krasowski wrote: > > It seems that the loop tried to access the memory regions > > beyond allocation, what caused crashes in not-so-rare cases, when > > the memory read did not belong to current process. > > > > This change is fixing the out-of-bounds read problem. > > Compiling this function with -fsanitize=address and running doesn't > > result in sanitizer warning as before. > > --- > > libavcodec/h2645_parse.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > have you seen/read the documentation for AV_INPUT_BUFFER_PADDING_SIZE > ? > > if not, that may be the cause of the issues you see > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Avoid a single point of failure, be that a person or equipment. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > -- Regards, Michał Krasowski Software Developer Opera TV Pl. Teatralny 8, 50-051 Wrocław, Polska This email may contain Opera confidential information and be protected by privilege. If you are not the intended recipient, any disclosure, copying, or use is prohibited. Please notify Opera immediately if you have received this message in error and delete all copies from your system. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
