| Message ID | CANn+0XNE51QYKGOzJMRYv2W7FR92yYW4DsRMJ0FE88BRk-4RnA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Hi, On Mon, May 8, 2017 at 3:08 PM, Zubin Mevawalla <zubinmeva@qbitlogic.com> wrote: > If `bufptr` is NULL, and `len` >= 12, then `buf` is initialized to NULL > and dereferenced on line 796. > > diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c > --- a/libavformat/rtpdec.c > +++ b/libavformat/rtpdec.c > @@ -793,8 +793,10 @@ static int rtp_parse_one_packet(RTPDemuxContext > *s, AVPacket *pkt, > if (len < 12) > return -1; > > - if ((buf[0] & 0xc0) != (RTP_VERSION << 6)) > In callers, we're assuming that (rtsp.c line 2158/2160) if len > 0, bufptr != NULL and thus buf != NULL. Likewise, len == 0 implies that bufptr == NULL and thus buf == NULL. Ronald
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c --- a/libavformat/rtpdec.c +++ b/libavformat/rtpdec.c @@ -793,8 +793,10 @@ static int rtp_parse_one_packet(RTPDemuxContext *s, AVPacket *pkt, if (len < 12) return -1; - if ((buf[0] & 0xc0) != (RTP_VERSION << 6)) + if(buf) { + if ((buf[0] & 0xc0) != (RTP_VERSION << 6)) return -1; + } if (RTP_PT_IS_RTCP(buf[1])) { return rtcp_parse_packet(s, buf, len);
I was curious if this is a real null pointer dereference issue? CodeAi, an automated repair tool being developed at Qbit logic, suggested an if-guard in libavformat/rtpdec.c on line 796 having seen a path through the control flow where an array access from `buf` results in a null pointer dereference. If `bufptr` is NULL, and `len` >= 12, then `buf` is initialized to NULL and dereferenced on line 796. } Could I submit this as a patch if it looks alright? Thanks so much, Zubin