[FFmpeg-devel] H263 decoding crash, [BUG] : reading memory past the end of the buffer.

[Pavel Pavlov]

> -----Original Message-----
> ...
> I'd be interested to know how you think that should work.
> Unless you assume debug builds are always run with valgrind...

My mistake sorry, it's possible to make sure than any algorithm
doesn't access memory past size + FF_INPUT_BUFFER_PADDING_SIZE (which
is useless), but not possible to detect that
FF_INPUT_BUFFER_PADDING_SIZE 
bytes past the end of the buffer are readable.


> Eric Bellotti wrote:
> > What the hell, man?  How am I supposed to know that code reads past 
> > buffer when I specify buffer size to avcodec_decode_video ?
> 
> Even if your mail was not meant for this list, the answer is:
> RTFD (read the fine documentation) before using a function.
> I paste the relevant part of avcodec.h for your convenience:
> 
> /**
>   * Decodes a video frame from \p buf into \p picture.
>   * The avcodec_decode_video() function decodes a video frame 
> from the input
>   * buffer \p buf of size \p buf_size. To decode it, it makes 
> use of the
>   * video codec which was coupled with \p avctx using 
> avcodec_open(). The
>   * resulting decoded frame is stored in \p picture.
>   *
>   * @warning The input buffer must be \c 
> FF_INPUT_BUFFER_PADDING_SIZE larger than
>   * the actual read bytes because some optimized bitstream 
> readers read
> 32 or 64
>   * bits at once and could read over the end.
> 
> ...
> 
>   */
> int avcodec_decode_video(AVCodecContext *avctx, AVFrame *picture,
>                           int *got_picture_ptr,
>                           const uint8_t *buf, int buf_size); 


We had that code working fine for many years and we always used some 
ancient dll's of ffmpeg, so there were no issues. I think we had that 
decoding code since around 2005-2006 and at that time 
avcodec_decode_video didn't even have any comments around it.
FF_INPUT_BUFFER_PADDING_SIZE was in avcodec.h at that time and had the
same 
description (I checked svn) but it doesn't change anything - it wasn't 
linked to avcodec_decode_video, so any code that still uses 
avcodec_decode_video and didn't add padding at the end of input stream
potentially will crash with certain input bistreams.
It's good that avcodec_decode_video will be removed from major 53, so
if any project uses ffmpeg and wants to update to the latest version
will
have to update their code and read comments near avcodec_decode_video2.