CVE-2017-14169 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14169): In the mxf_read_primer_pack function in libavformat/mxfdec.c in FFmpeg 3.3.3, an integer signedness error might occur when a crafted file, which claims a large "item_num" field such as 0xffffffff, is provided. As a result, the variable "item_num" turns negative, bypassing the check for a large value. References: https://github.com/FFmpeg/FFmpeg/commit/9d00fb9d70ee8c0cc7002b89318c5be00f1bbdad CVE-2017-14170 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14170): In libavformat/mxfdec.c in FFmpeg 3.3.3, a DoS in mxf_read_index_entry_array() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted MXF file, which claims a large "nb_index_entries" field in the header but does not contain sufficient backing data, is provided, the loop would consume huge CPU resources, since there is no EOF check inside the loop. Moreover, this big loop can be invoked multiple times if there is more than one applicable data segment in the crafted MXF file. References: https://github.com/FFmpeg/FFmpeg/commit/900f39692ca0337a98a7cf047e4e2611071810c2 CVE-2017-14171 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14171): In libavformat/nsvdec.c in FFmpeg 3.3.3, a DoS in nsv_parse_NSVf_header() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted NSV file, which claims a large "table_entries_used" field in the header but does not contain sufficient backing data, is provided, the loop over 'table_entries_used' would consume huge CPU resources, since there is no EOF check inside the loop. References: https://github.com/FFmpeg/FFmpeg/commit/c24bcb553650b91e9eff15ef6e54ca73de2453b7
this is fixed in 3.3.4 which can go stable
Stabilization will occur on bug 630460.
GLSA Vote: No Cleanup handled in bug #630460
