[FFmpeg-devel] [PATCH 2/3] avcodec/siren: Check available bits at frame start

[James Almer]

On 9/29/2021 12:31 PM, Michael Niedermayer wrote:
> On Tue, Sep 28, 2021 at 10:19:48PM -0300, James Almer wrote:
>> On 9/28/2021 7:28 PM, Michael Niedermayer wrote:
>>> Fixes: Timeout
>>> Fixes: 39089/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSNSIREN_fuzzer-6677219854909440
>>>
>>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Suggested-by: James Almer <jamrial at gmail.com>
>>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>>> ---
>>>    libavcodec/siren.c | 6 +++++-
>>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/siren.c b/libavcodec/siren.c
>>> index 7f084172a4c..8c9628e2d8e 100644
>>> --- a/libavcodec/siren.c
>>> +++ b/libavcodec/siren.c
>>> @@ -447,6 +447,8 @@ static int decode_envelope(SirenContext *s, GetBitContext *gb,
>>>            int index = 0;
>>>            do {
>>> +            if (get_bits_left(gb) < 4)
>>
>> If the idea is that there will be enough bits to read rate_control after
>> this function returns, then this should also take into account the
>> get_bits1() below.
> 
> Do you suggest that this is merged with 3/3 or do you suggest something else ?

I was thinking making this a < 5 check, so it's guaranteed there's one 
for index inside this do while loop plus four for rate_control after 
returning from this function, but i hadn't looked at the 3/3 patch when 
i wrote that, and now i see it actually adds a consideration for that.

LGTM then. And no opinion about squashing them. Do as you prefer.

> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>