CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2017-14223
https://notcve.org/view.php?id=CVE-2017-14223
In libavformat/asfdec_f.c in FFmpeg 3.3.3, a DoS in asf_build_simple_index() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted ASF file, which claims a large "ict" field in the header but does not contain sufficient backing data, is provided, the for loop would consume huge CPU and memory resources, since there is no EOF check inside the loop. En libavformat/asfdec_f.c en FFmpeg 3.3.3, una denegación de servicio en asf_build_simple_index() debido a una falta de comprobación EOE (End of File) podría provocar un gran consumo de CPU. Cuando se proporciona un archivo ASF manipulado, que reclama un gran campo "ict" en el encabezado pero que no contiene datos de respaldo suficientes, el bucle for consumiría una gran cantidad de recursos de CPU y de memoria, ya que no existe una comprobación EOF dentro del bucle. • http://www.debian.org/security/2017/dsa-3996 http://www.securityfocus.com/bid/100703 https://github.com/FFmpeg/FFmpeg/commit/afc9c683ed9db01edb357bc8c19edad4282b3a97 https://lists.debian.org/debian-lts-announce/2019/02/msg00005.html • CWE-400: Uncontrolled Resource Consumption •
CVSS: 7.1EPSS: 0%CPEs: 1EXPL: 0CVE-2017-14222
https://notcve.org/view.php?id=CVE-2017-14222
In libavformat/mov.c in FFmpeg 3.3.3, a DoS in read_tfra() due to lack of an EOF (End of File) check might cause huge CPU and memory consumption. When a crafted MOV file, which claims a large "item_count" field in the header but does not contain sufficient backing data, is provided, the loop would consume huge CPU and memory resources, since there is no EOF check inside the loop. En libavformat/mov.c en FFmpeg 3.3.3, una denegación de servicio en read_tfra() debido a una falta de comprobación EOE (End of File) podría provocar un gran consumo de CPU y memoria. Cuando se proporciona un archivo MOV manipulado, que reclama un gran campo "item_count" en el encabezado pero que no contiene datos de respaldo suficientes, el bucle consumiría una gran cantidad de recursos de CPU y de memoria, ya que no existe una comprobación EOF dentro del bucle. • http://www.debian.org/security/2017/dsa-3996 http://www.securityfocus.com/bid/100701 https://github.com/FFmpeg/FFmpeg/commit/9cb4eb772839c5e1de2855d126bf74ff16d13382 • CWE-834: Excessive Iteration •
CVSS: 7.1EPSS: 0%CPEs: 1EXPL: 0CVE-2017-14170
https://notcve.org/view.php?id=CVE-2017-14170
In libavformat/mxfdec.c in FFmpeg 3.3.3 -> 2.4, 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. En libavformat/mxfdec.c en FFmpeg versión 3.3.3 mayor a 2.4, en DoS una denegación de servicio en mxf_read_index_entry_array() por una falta de chequeos EOF (End of File) podría provocar un enorme consumo de recursos de la CPU. Cuando se proporciona un archivo MXF manipulado que pide un campo "nb_index_entries" grande en la cabecera pero no contiene suficientes datos de respaldo, el bucle consumiría una gran cantidad de recursos de CPU, ya que el bucle no contiene ningún chequeo EOF. • http://www.debian.org/security/2017/dsa-3996 http://www.securityfocus.com/bid/100700 https://github.com/FFmpeg/FFmpeg/commit/900f39692ca0337a98a7cf047e4e2611071810c2 https://github.com/FFmpeg/FFmpeg/commit/f173cdfe669556aa92857adafe60cbe5f2aa1210 https://lists.debian.org/debian-lts-announce/2019/01/msg00006.html • CWE-834: Excessive Iteration •
CVSS: 8.8EPSS: 0%CPEs: 3EXPL: 0CVE-2017-14169
https://notcve.org/view.php?id=CVE-2017-14169
In the mxf_read_primer_pack function in libavformat/mxfdec.c in FFmpeg 3.3.3 -> 2.4, 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. En la función mxf_read_primer_pack en libavformat/mxfdec.c en FFmpeg versión 3.3.3 mayor a 2.4, podría ocurrir un error de firmas de enteros cuando se proporciona un archivo manipulado que reclame un campo "item_num" grande como 0xffffffff. Como consecuencia, la variable "item_num" se vuelve negativa, omitiendo el chequeo de valores grandes • http://www.debian.org/security/2017/dsa-3996 http://www.securityfocus.com/bid/100692 https://github.com/FFmpeg/FFmpeg/commit/9d00fb9d70ee8c0cc7002b89318c5be00f1bbdad https://github.com/FFmpeg/FFmpeg/commit/a4e85b2e1c8d5b4bf0091157bbdeb0e457fb7b8f https://lists.debian.org/debian-lts-announce/2019/02/msg00005.html • CWE-20: Improper Input Validation •
CVSS: 7.1EPSS: 0%CPEs: 1EXPL: 0CVE-2017-14171
https://notcve.org/view.php?id=CVE-2017-14171
In libavformat/nsvdec.c in FFmpeg 2.4 and 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. En libavformat/nsvdec.c en FFmpeg versión 2.4 y 3.3.3, una denegación de servicio en nsv_parse_NSVf_header() por una falta de chequeos EOF (End of File) podría provocar un enorme consumo de recursos de la CPU. Cuando se proporciona un archivo NSV manipulado que pide un campo "table_entries_used" grande en la cabecera pero no contiene suficientes datos de respaldo, el bucle en "table_entries_used" consumiría una gran cantidad de recursos de CPU, ya que el bucle no contiene ningún chequeo EOF • http://www.debian.org/security/2017/dsa-3996 http://www.securityfocus.com/bid/100706 https://github.com/FFmpeg/FFmpeg/commit/c24bcb553650b91e9eff15ef6e54ca73de2453b7 https://lists.debian.org/debian-lts-announce/2019/01/msg00006.html • CWE-834: Excessive Iteration •