On 1/22/2021 7:10 PM, Michael Niedermayer wrote:
On Fri, Jan 22, 2021 at 11:23:09AM -0300, James Almer wrote:
On 1/22/2021 11:09 AM, Michael Niedermayer wrote:
Fixes: signed integer overflow: 9223372036854775723 + 8192 cannot be
represented in type 'long'
Fixes:
29072/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4812604904177664
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
---
libavformat/mxfdec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 4c932e954c..f1167761f9 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2865,8 +2865,10 @@ static int mxf_read_local_tags(MXFContext *mxf,
KLVPacket *klv, MXFMetadataReadF
int ret;
int tag = avio_rb16(pb);
int size = avio_rb16(pb); /* KLV specified by 0x53 */
- uint64_t next = avio_tell(pb) + size;
+ uint64_t next = avio_tell(pb);
UID uid = {0};
+ if (next > INT64_MAX - size)
+ size = 0;
You're discarding the tag's size. The code below could misbehave as it will
assume it's an empty tag when it's not. Not to mention the log message will
print a bogus value.
Abort instead (Invalid data or erange) in this scenario since going beyond
INT64_MAX is clearly not supported by avio, and then do next += size to
ensure the avio_seek() at the end works as expected.
I dont think this strictly implies being beyond INT64_MAX.
but i wanted to redo this patch anyway as it contained another bug
so next suggestion:
@@ -2865,8 +2865,11 @@ static int mxf_read_local_tags(MXFContext *mxf,
KLVPacket *klv, MXFMetadataReadF
int ret;
int tag = avio_rb16(pb);
int size = avio_rb16(pb); /* KLV specified by 0x53 */
- uint64_t next = avio_tell(pb) + size;
+ int64_t next = avio_tell(pb);
UID uid = {0};
+ if (next < 0 || next > INT64_MAX - size)
+ return next < 0 ? next : AVERROR_INVALIDDATA;
+ next += size;
av_log(mxf->fc, AV_LOG_TRACE, "local tag %#04x size %d\n", tag, size);
if (!size) { /* ignore empty tag, needed for some files with empty
UMID tag */
thx
That's better, yes.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
