[FFmpeg-devel] [PATCH 3/3] avformat/mov: fix the entry count overflow check in the keys atom

James Almer jamrial at gmail.com
Tue Apr 2 15:05:03 EEST 2024


On 4/2/2024 12:30 AM, Andreas Rheinhardt wrote:
> James Almer:
>> Signed-off-by: James Almer <jamrial at gmail.com>
>> ---
>>   libavformat/mov.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index a935ef7326..9fca402896 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -5025,7 +5025,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>>       avio_skip(pb, 4);
>>       count = avio_rb32(pb);
>>       atom.size -= 8;
>> -    if (count > UINT_MAX / sizeof(*c->meta_keys) - 1) {
>> +    if (count + 1LL > UINT_MAX / sizeof(*c->meta_keys)) {
>>           av_log(c->fc, AV_LOG_ERROR,
>>                  "The 'keys' atom with the invalid key count: %"PRIu32"\n", count);
>>           return AVERROR_INVALIDDATA;
> 
> What is supposed to be wrong here in the first place? The only thing I
> can think of is the case in which sizeof(*c->meta_keys) is > UINT_MAX,
> in which case the rhs would wrap around. But I don't think that is what
> you meant given that sizeof(*c->meta_keys) == sizeof(char*).
> Anyway, a simpler check that works even if sizeof(*c->meta_keys) were
> insanely large is "count >= UINT_MAX / sizeof(*c->meta_keys)".

I misread the check, so there's nothing wrong with it. But I'll apply 
that suggestion of yours in any case since it's simpler than the current 
one.


More information about the ffmpeg-devel mailing list