On 2012-11-26 07:01:20 -0800, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Nov 26, 2012 at 4:06 AM, Janne Grunau <janne-li...@jannau.net> wrote:
> > Fixes segfault in the fuzzed sample bipbop234.ts_s226407.
> >
> > CC: libav-sta...@libav.org
> > ---
> > libavcodec/h264.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> > index eca4636..730e34a 100644
> > --- a/libavcodec/h264.c
> > +++ b/libavcodec/h264.c
> > @@ -2896,8 +2896,13 @@ static int decode_slice_header(H264Context *h,
> > H264Context *h0)
> >
> > if (num_ref_idx_active_override_flag) {
> > h->ref_count[0] = get_ue_golomb(&s->gb) + 1;
> > - if (h->slice_type_nos == AV_PICTURE_TYPE_B)
> > + if (h->ref_count[0] < 1)
> > + return AVERROR_INVALIDDATA;
> > + if (h->slice_type_nos == AV_PICTURE_TYPE_B) {
> > h->ref_count[1] = get_ue_golomb(&s->gb) + 1;
> > + if (h->ref_count[1] < 1)
> > + return AVERROR_INVALIDDATA;
> > + }
> > }
> >
> > if (h->slice_type_nos == AV_PICTURE_TYPE_B)
> > --
> > 1.7.12.4
>
> get_ue_golomb() guarantees to return something non-negative, so is
> this an integer overflow? We should then prevent the integer overflow.
It returns -1 if the next 32 bits are all 0. That is arguebly not a
valid exp-golomb code but occurs with the sample mentioned in the commit
message (available in incoming/2012-11-15_fuzz_h264_janne as my other
fuzzed samples).
Janne
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
