Re: [FFmpeg-devel] [PATCH] Fix potential integer overflow in mov_read_keys
On Wed, Sep 07, 2016 at 02:38:48PM -0700, Sergey Volk wrote: > I just realized that count+1 itself might overflow if count==UINT_MAX, so I > guess it's better to subtract 1 from the right-hand side. Attached updated > patch. > > On Wed, Sep 7, 2016 at 2:21 PM, Sergey Volkwrote: > > > Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so > > we need to check that (count + 1) won't cause overflow. > > > > > mov.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 5f372bd81ec31f48d8a4b78f82a4ab9c82a9bb43 > 0001-Fix-potential-integer-overflow-in-mov_read_keys.patch > From 87a7a2e202ebb63362715054773a89ce1fc71743 Mon Sep 17 00:00:00 2001 > From: Sergey Volk > Date: Wed, 7 Sep 2016 14:05:35 -0700 > Subject: [PATCH] Fix potential integer overflow in mov_read_keys > > Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so > we need to check that (count + 1) won't cause overflow. > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix potential integer overflow in mov_read_keys
I just realized that count+1 itself might overflow if count==UINT_MAX, so I guess it's better to subtract 1 from the right-hand side. Attached updated patch. On Wed, Sep 7, 2016 at 2:21 PM, Sergey Volkwrote: > Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so > we need to check that (count + 1) won't cause overflow. > > From 87a7a2e202ebb63362715054773a89ce1fc71743 Mon Sep 17 00:00:00 2001 From: Sergey Volk Date: Wed, 7 Sep 2016 14:05:35 -0700 Subject: [PATCH] Fix potential integer overflow in mov_read_keys Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so we need to check that (count + 1) won't cause overflow. --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index f499906..a7595c5 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -3278,7 +3278,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom) avio_skip(pb, 4); count = avio_rb32(pb); -if (count > UINT_MAX / sizeof(*c->meta_keys)) { +if (count > UINT_MAX / sizeof(*c->meta_keys) - 1) { av_log(c->fc, AV_LOG_ERROR, "The 'keys' atom with the invalid key count: %d\n", count); return AVERROR_INVALIDDATA; -- 2.8.0.rc3.226.g39d4020 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix potential integer overflow in mov_read_keys
Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so we need to check that (count + 1) won't cause overflow. From cfc0f5a099284c95476d5c020dca05fb743ff5ae Mon Sep 17 00:00:00 2001 From: Sergey VolkDate: Wed, 7 Sep 2016 14:05:35 -0700 Subject: [PATCH] Fix potential integer overflow in mov_read_keys Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so we need to check that (count + 1) won't cause overflow. --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index f499906..ea7d051 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -3278,7 +3278,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom) avio_skip(pb, 4); count = avio_rb32(pb); -if (count > UINT_MAX / sizeof(*c->meta_keys)) { +if (count + 1 > UINT_MAX / sizeof(*c->meta_keys)) { av_log(c->fc, AV_LOG_ERROR, "The 'keys' atom with the invalid key count: %d\n", count); return AVERROR_INVALIDDATA; -- 2.8.0.rc3.226.g39d4020 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel