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 <jamr...@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@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
