[FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[James Almer]

On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
>> This prevents leaks in the rare cases the function is called when extradata
>> already exists.
>>
>> Signed-off-by: James Almer <jamrial at gmail.com>
>> ---
>>  libavformat/utils.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 72531d4185..31340a484b 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int size)
>>  {
>>      int ret;
>>  
>> +    av_freep(&par->extradata);
>>      if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
>>          par->extradata = NULL;
>>          par->extradata_size = 0;
> 
> This causes memory corruption
> ...
> [mpegts @ 0x7f8c74000a80] PES packet size mismatch
> *** Error in `./ffplay': double free or corruption (fasttop): 0x00007f8c7402d9c0 ***
> Aborted (core dumped)

Is something freeing extradata and leaving a dangling pointer before
eventually calling ff_alloc_extradata()?
At least the two calls in mpegts.c don't seem to do that.

> 
> I think this should not have been applied so quickly, i tested it as soon as i
> had time and saw it but it was applied already

Fate passed when i tested it, and i got a positive review from the
author of the function in question, that's why i pushed it. Sorry.

> 
> If it helps i can debug the cases i see to find out which calls cause them but
> someone will still have to review all call sites probably for this change to
> be safe

Yes, help would be welcome. Crashes like this probably hint at frees
leaving dangling pointers across the codebase.

> 
> 
> [...]
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>