It looks like this could lead to security issues, as side data readers
will for example rely on side data allocation sizes to be as large as
needed for correct operation. If such files exist at all, they also
should be brought out of circulation, so fully reject them. Under normal
circumstances, nothing creates such files.
To avoid problems for now, we let the concat and hls demuxers do this
(they merely return previously-demuxed packets, whose side data might
have been merged by libavformat itself after demuxing). The
special-cases will be removed in the next commit.
---
libavformat/utils.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 37d7024465..68f3c977d6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -840,6 +840,15 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
*pkt = tmp;
}
+ if (strcmp(s->iformat->name, "concat") && strcmp(s->iformat->name,
"hls,applehttp")
+ && av_packet_split_side_data(pkt) == 1) {
+ av_log(s, AV_LOG_ERROR,
+ "FFmpeg-style merged side data found in raw packet. "
+ "The packet is rejected for security reasons.\n");
+ av_packet_unref(pkt);
+ return AVERROR_INVALIDDATA;
+ }
+
if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT) &&
(pkt->flags & AV_PKT_FLAG_CORRUPT)) {
av_log(s, AV_LOG_WARNING,
--
2.11.0
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
