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

[James Almer]

On 3/6/2018 11:40 PM, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 11:27:54PM -0300, James Almer wrote:
>> On 3/6/2018 11:03 PM, James Almer wrote:
>>> 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.
>>
>> Does the attached patch fix this crash?
> 
> yes, thanks!

Pushed. Sorry again for the regression.