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 <[email protected]>
> 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 <[email protected]> > 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 <[email protected]> > --- > libavformat/mov.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
