[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