Message ID | CAPUDrwc78FJr94=cQYsj2XfP6yJubgYAN5a0aLw8B6CnUiLTHA@mail.gmail.com |
---|---|
State | New |
Headers | show |
On Thu, Aug 30, 2018 at 03:21:02PM -0700, Dale Curtis wrote: > Entries are always at least 8 bytes per the parsing code, so if we > see an impossible entry count avoid massive allocations. This is > similar to an existing check in mov_read_stsc(). > > Since ff_mov_read_stsd_entries() does eof checks, an alternative > approach could be to clamp the entry count to atom.size / 8. > > Signed-off-by: Dale Curtis <dalecurtis@chromium.org> > mov.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > 3678e5a185138a43c4f5dc4eb54283900e0e74c8 0001-Error-on-too-large-stsd-entry-counts.patch > From 3e1663d84068ff7615f7e84fa1c1122729a531da Mon Sep 17 00:00:00 2001 > From: Dale Curtis <dalecurtis@chromium.org> > Date: Thu, 30 Aug 2018 15:18:25 -0700 > Subject: [PATCH] Error on too large stsd entry counts. > > Entries are always at least 8 bytes per the parsing code, so if we > see an impossible entry count avoid massive allocations. This is > similar to an existing check in mov_read_stsc(). > > Since ff_mov_read_stsd_entries() does eof checks, an alternative > approach could be to clamp the entry count to atom.size / 8. > > Signed-off-by: Dale Curtis <dalecurtis@chromium.org> > --- > libavformat/mov.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) will apply thx [...]
From 3e1663d84068ff7615f7e84fa1c1122729a531da Mon Sep 17 00:00:00 2001 From: Dale Curtis <dalecurtis@chromium.org> Date: Thu, 30 Aug 2018 15:18:25 -0700 Subject: [PATCH] Error on too large stsd entry counts. Entries are always at least 8 bytes per the parsing code, so if we see an impossible entry count avoid massive allocations. This is similar to an existing check in mov_read_stsc(). Since ff_mov_read_stsd_entries() does eof checks, an alternative approach could be to clamp the entry count to atom.size / 8. Signed-off-by: Dale Curtis <dalecurtis@chromium.org> --- libavformat/mov.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index d66f4e338c..d922e0f173 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2558,7 +2558,8 @@ static int mov_read_stsd(MOVContext *c, AVIOContext *pb, MOVAtom atom) avio_rb24(pb); /* flags */ entries = avio_rb32(pb); - if (entries <= 0) { + /* Each entry contains a size (4 bytes) and format (4 bytes). */ + if (entries <= 0 || entries > atom.size / 8) { av_log(c->fc, AV_LOG_ERROR, "invalid STSD entries %d\n", entries); return AVERROR_INVALIDDATA; } -- 2.19.0.rc0.228.g281dcd1b4d0-goog
Entries are always at least 8 bytes per the parsing code, so if we see an impossible entry count avoid massive allocations. This is similar to an existing check in mov_read_stsc(). Since ff_mov_read_stsd_entries() does eof checks, an alternative approach could be to clamp the entry count to atom.size / 8. Signed-off-by: Dale Curtis <dalecurtis@chromium.org>