| Message ID | 20231108021244.8669-1-michael@niedermayer.cc |
|---|---|
| State | Accepted |
| Commit | 19fcf4313148e86aa47d81a8d5d5e8d056f1f906 |
| Headers | show |
| Series | [FFmpeg-devel,1/3] avformat/mov: Disallow FTYP after streams | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
FWIW, this ends up breaking files which are basically just concatenated fragmented mp4 files -- which is pretty sketchy, but we had some test content doing that: https://storage.googleapis.com/chromiumos-test-assets-public/Shaka-Dash/switch_1080p_720p.mp4 Is that intentional? Or should an alternate fix where duplicate ftyp is ignored be considered? - dale On Tue, Nov 7, 2023 at 6:12 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > Fixes: Assertion !c->fc->nb_streams failed at libavformat/mov.c:7799 > Fixes: > 63875/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5479178702815232 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > Michael Niedermayer <michael@niedermayer.cc> > --- > libavformat/mov.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index e8efccf6ebf..34ca8095c22 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -1222,6 +1222,8 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext > *pb, MOVAtom atom) > int ret = ffio_read_size(pb, type, 4); > if (ret < 0) > return ret; > + if (c->fc->nb_streams) > + return AVERROR_INVALIDDATA; > > if (strcmp(type, "qt ")) > c->isom = 1; > -- > 2.17.1 > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Fri, Dec 01, 2023 at 10:27:20AM -0800, Dale Curtis wrote: > FWIW, this ends up breaking files which are basically just > concatenated fragmented mp4 files -- which is pretty sketchy, but we had > some test content doing that: > https://storage.googleapis.com/chromiumos-test-assets-public/Shaka-Dash/switch_1080p_720p.mp4 > > Is that intentional? Or should an alternate fix where duplicate ftyp is > ignored be considered? i was unaware that this actually occurs patch ignoring it posted thx [...]
diff --git a/libavformat/mov.c b/libavformat/mov.c index e8efccf6ebf..34ca8095c22 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -1222,6 +1222,8 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext *pb, MOVAtom atom) int ret = ffio_read_size(pb, type, 4); if (ret < 0) return ret; + if (c->fc->nb_streams) + return AVERROR_INVALIDDATA; if (strcmp(type, "qt ")) c->isom = 1;
Fixes: Assertion !c->fc->nb_streams failed at libavformat/mov.c:7799 Fixes: 63875/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5479178702815232 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavformat/mov.c | 2 ++ 1 file changed, 2 insertions(+)