[FFmpeg-devel] [PATCH 6/7] lavf/flacenc: avoid buffer overread with unexpected extradata sizes

Rostislav Pehlivanov atomnuker at gmail.com
Wed Nov 22 03:03:14 EET 2017


On 2 August 2017 at 00:35, Rodger Combs <rodger.combs at gmail.com> wrote:

>
> > On Aug 1, 2017, at 18:25, James Almer <jamrial at gmail.com> wrote:
> >
> > On 8/1/2017 3:33 AM, Rodger Combs wrote:
> >> ---
> >> libavformat/flacenc.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> >> index 9768b6a..1906aee 100644
> >> --- a/libavformat/flacenc.c
> >> +++ b/libavformat/flacenc.c
> >> @@ -322,7 +322,7 @@ static int flac_write_trailer(struct
> AVFormatContext *s)
> >>     if (!c->write_header || !streaminfo)
> >>         return 0;
> >>
> >> -    if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> >> +    if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo ||
> s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) {
> >
> > In what situation would stream extradata or c->streaminfo be smaller
> > than FLAC_STREAMINFO_SIZE? Nothing changes par->extradata anywhere, and
> > c->streaminfo is always allocated with FLAC_STREAMINFO_SIZE bytes of
> memory.
> > I have the feeling i already asked this before, but not sure if you
> > answered it. Apologies if you did.
>
> It shouldn't happen in normal cases, but you could imagine a case with
> remuxing a corrupted input file.
>

Shouldn't the demuxer handle this?


More information about the ffmpeg-devel mailing list