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

[Rodger Combs]

> On Nov 21, 2017, at 19:03, Rostislav Pehlivanov <atomnuker at gmail.com> wrote:
> 
> On 2 August 2017 at 00:35, Rodger Combs <rodger.combs at gmail.com <mailto: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?

Even in e.g. MKV?

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org <mailto:ffmpeg-devel at ffmpeg.org>
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>