On Mon, Nov 26, 2012 at 7:54 AM, Janne Grunau <janne-li...@jannau.net> wrote:
> 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).
Oh I see, patch OK then.
Ronald
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
