[FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference
Hendrik Leppkes
h.leppkes at gmail.com
Sat Oct 24 16:46:15 CEST 2015
On Sat, Oct 24, 2015 at 3:26 PM, Ganesh Ajjanagadde
<gajjanagadde at gmail.com> wrote:
> On Sat, Oct 24, 2015 at 9:15 AM, Nicolas George <george at nsup.org> wrote:
>> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>>> Fixes CID 1322329.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
>>> ---
>>> libavcodec/pthread_frame.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
>>> index 7651211..ca06e3d 100644
>>> --- a/libavcodec/pthread_frame.c
>>> +++ b/libavcodec/pthread_frame.c
>>> @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p)
>>> pthread_mutex_lock(&fctx->buffer_mutex);
>>>
>>> // fix extended data in case the caller screwed it up
>>> - av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
>>
>>> + av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
>>
>> I think the commit message should explain in what circumstances p->avctx can
>> be NULL. Otherwise, the extra test is only hiding a problem earlier in the
>> code.
>
> Ok, will check in more detail. Thanks.
>
More the the point, if this actually can be NULL, then an assert is
not what should check that, since asserts are just like crashes (even
if safer from a security point)
If it can't be NULL, then it seems like a false positive.
- Hendrik
More information about the ffmpeg-devel
mailing list