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

[Michał Krasowski]

@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 <michael at 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 at 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.