Security update for ffmpeg, ffmpeg2 (important)

This update introduces lame and twolame.

For ffmpeg2 it updates to version 2.8.13 and fixes several issues.

These security issues were fixed:

• CVE-2017-14058: The read_data function in libavformat/hls.c did not
  restrict reload attempts for an insufficient list, which allowed remote
  attackers to cause a denial of service (infinite loop) (bsc#1056762).
• CVE-2017-14057: In asf_read_marker() due to lack of an EOF (End of File)
  check might have caused huge CPU and memory consumption. When a crafted
  ASF file, which claims a large "name_len" or "count" field in the header
  but did not contain sufficient backing data, was provided, the loops
  over the name and markers would consume huge CPU and memory resources,
  since there is no EOF check inside these loops (bsc#1056761).
• CVE-2017-14059: A DoS in cine_read_header() due to lack of an EOF check
  might have caused huge CPU and memory consumption. When a crafted CINE
  file, which claims a large "duration" field in the header but did not
  contain sufficient backing data, was provided, the image-offset parsing
  loop would consume huge CPU and memory resources, since there is no EOF
  check inside the loop (bsc#1056763).
• CVE-2017-14056: A DoS in rl2_read_header() due to lack of an EOF (End of
  File) check might have caused huge CPU and memory consumption. When a
  crafted RL2 file, which claims a large "frame_count" field in the header
  but did not contain sufficient backing data, was provided, the loops
  (for offset and size tables) would consume huge CPU and memory
  resources, since there is no EOF check inside these loops (bsc#1056760).
• CVE-2017-14055: a DoS in mv_read_header() due to lack of an EOF (End of
  File) check might have caused huge CPU and memory consumption. When a
  crafted MV file, which claims a large "nb_frames" field in the header
  but did not contain sufficient backing data, was provided, the loop over
  the frames would consume huge CPU and memory resources, since there is
  no EOF check inside the loop (bsc#1056766).
• boo#1046211: Lots of integer overflow fixes
• CVE-2016-9561: The che_configure function in
  libavcodec/aacdec_template.c in FFmpeg allowed remote attackers to cause
  a denial of service (allocation of huge memory, and being killed by the
  OS) via a crafted MOV file (boo#1015120)
• CVE-2017-7863: FFmpeg had an out-of-bounds write caused by a heap-based
  buffer overflow related to the decode_frame_common function in
  libavcodec/pngdec.c (boo#1034179)
• CVE-2017-7865: FFmpeg had an out-of-bounds write caused by a heap-based
  buffer overflow related to the ipvideo_decode_block_opcode_0xA function
  in libavcodec/interplayvideo.c and the avcodec_align_dimensions2
  function in libavcodec/utils.c (boo#1034177)
• CVE-2017-7866: FFmpeg had an out-of-bounds write caused by a stack-based
  buffer overflow related to the decode_zbuf function in
  libavcodec/pngdec.c (boo#1034176)
• CVE-2016-10190: Heap-based buffer overflow in libavformat/http.c in
  FFmpeg allowed remote web servers to execute arbitrary code via a
  negative chunk size in an HTTP response (boo#1022920)
• CVE-2016-10191: Heap-based buffer overflow in libavformat/rtmppkt.c in
  FFmpeg allowed remote attackers to execute arbitrary code by leveraging
  failure to check for RTMP packet size mismatches (boo#1022921)
• CVE-2016-10192: Heap-based buffer overflow in ffserver.c in FFmpeg
  allowed remote attackers to execute arbitrary code by leveraging failure
  to check chunk size (boo#1022922)
• CVE-2017-14169: In the mxf_read_primer_pack function an integer
  signedness error have might occured when a crafted file, which claims a
  large "item_num" field such as 0xffffffff, was provided. As a result,
  the variable "item_num" turns negative, bypassing the check for a large
  value (bsc#1057536).
• CVE-2017-14170: Prevent DoS in mxf_read_index_entry_array() due to lack
  of an EOF (End of File) check that might have caused huge CPU
  consumption. When a crafted MXF file, which claims a large
  "nb_index_entries" field in the header but did not contain sufficient
  backing data, was provided, the loop would consume huge CPU resources,
  since there was 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 (bsc#1057537).
• CVE-2017-14171: Prevent DoS in nsv_parse_NSVf_header() due to lack of an
  EOF (End of File) check taht might have caused huge CPU consumption.
  When a crafted NSV file, which claims a large "table_entries_used" field
  in the header but did not contain sufficient backing data, was provided,
  the loop over ‘table_entries_used’ would consume huge CPU resources,
  since there was no EOF check inside the loop (bsc#1057539).
• CVE-2017-14223: Prevent DoS in asf_build_simple_index() due to lack of
  an EOF (End of File) check that might have caused huge CPU consumption.
  When a crafted ASF file, which claims a large "ict" field in the header
  but did not contain sufficient backing data, was provided, the for loop
  would consume huge CPU and memory resources, since there was no EOF
  check inside the loop (bsc#1058019)
• CVE-2017-14222: Prevent DoS in read_tfra() due to lack of an EOF (End of
  File) check that might have caused huge CPU and memory consumption. When
  a crafted MOV file, which claims a large "item_count" field in the
  header but did not contain sufficient backing data, was provided, the
  loop would consume huge CPU and memory resources, since there was no EOF
  check inside the loop (bsc#1058020)

These non-security issues were fixed:

• Unconditionalize celt, ass, openjpeg, webp, libva, vdpau.
• Build unconditionally with lame and twolame
• Enable AC3 and MP3 decoding to match multimedia:libs/ffmpeg (3.x)

For ffmpeg it updates to version 3.3.4 and fixes several issues.

These security issues were fixed:

• CVE-2017-14225: The av_color_primaries_name function may have returned a
  NULL pointer depending on a value contained in a file, but callers did
  not anticipate this, leading to a NULL pointer dereference (bsc#1058018).
• CVE-2017-14223: Prevent DoS in asf_build_simple_index() due to lack of
  an EOF (End of File) check that might have caused huge CPU consumption.
  When a crafted ASF file, which claims a large "ict" field in the header
  but did not contain sufficient backing data, was provided, the for loop
  would consume huge CPU and memory resources, since there was no EOF
  check inside the loop (bsc#1058019).
• CVE-2017-14222: Prevent DoS in read_tfra() due to lack of an EOF (End of
  File) check that might have caused huge CPU and memory consumption. When
  a crafted MOV file, which claims a large "item_count" field in the
  header but did not contain sufficient backing data, was provided, the
  loop would consume huge CPU and memory resources, since there was no EOF
  check inside the loop (bsc#1058020).
• CVE-2017-14058: The read_data function in libavformat/hls.c did not
  restrict reload attempts for an insufficient list, which allowed remote
  attackers to cause a denial of service (infinite loop) (bsc#1056762)
• CVE-2017-14057: In asf_read_marker() due to lack of an EOF (End of File)
  check might have caused huge CPU and memory consumption. When a crafted
  ASF file, which claims a large "name_len" or "count" field in the header
  but did not contain sufficient backing data, was provided, the loops
  over the name and markers would consume huge CPU and memory resources,
  since there is no EOF check inside these loops (bsc#1056761)
• CVE-2017-14059: A DoS in cine_read_header() due to lack of an EOF check
  might have caused huge CPU and memory consumption. When a crafted CINE
  file, which claims a large "duration" field in the header but did not
  contain sufficient backing data, was provided, the image-offset parsing
  loop would consume huge CPU and memory resources, since there is no EOF
  check inside the loop (bsc#1056763)
• CVE-2017-14054: A DoS in ivr_read_header() due to lack of an EOF (End of
  File) check might have caused huge CPU consumption. When a crafted IVR
  file, which claims a large "len" field in the header but did not contain
  sufficient backing data, was provided, the first type==4 loop would
  consume huge CPU resources, since there is no EOF check inside the loop
  (bsc#1056765).
• CVE-2017-14056: A DoS in rl2_read_header() due to lack of an EOF (End of
  File) check might have caused huge CPU and memory consumption. When a
  crafted RL2 file, which claims a large "frame_count" field in the header
  but did not contain sufficient backing data, was provided, the loops
  (for offset and size tables) would consume huge CPU and memory
  resources, since there is no EOF check inside these loops (bsc#1056760)
• CVE-2017-14055: a DoS in mv_read_header() due to lack of an EOF (End of
  File) check might have caused huge CPU and memory consumption. When a
  crafted MV file, which claims a large "nb_frames" field in the header
  but did not contain sufficient backing data, was provided, the loop over
  the frames would consume huge CPU and memory resources, since there is
  no EOF check inside the loop (bsc#1056766)
• CVE-2017-11399: Integer overflow in the ape_decode_frame function
  allowed remote attackers to cause a denial of service (out-of-array
  access and application crash) or possibly have unspecified other impact
  via a crafted APE file (bsc#1049095).
• CVE-2017-14171: Prevent DoS in nsv_parse_NSVf_header() due to lack of an
  EOF (End of File) check taht might have caused huge CPU consumption.
  When a crafted NSV file, which claims a large "table_entries_used" field
  in the header but did not contain sufficient backing data, was provided,
  the loop over ‘table_entries_used’ would consume huge CPU resources,
  since there was no EOF check inside the loop (bsc#1057539)
• CVE-2017-14170: Prevent DoS in mxf_read_index_entry_array() due to lack
  of an EOF (End of File) check that might have caused huge CPU
  consumption. When a crafted MXF file, which claims a large
  "nb_index_entries" field in the header but did not contain sufficient
  backing data, was provided, the loop would consume huge CPU resources,
  since there was 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 (bsc#1057537)
• CVE-2017-14169: In the mxf_read_primer_pack function an integer
  signedness error have might occured when a crafted file, which claims a
  large "item_num" field such as 0xffffffff, was provided. As a result,
  the variable "item_num" turns negative, bypassing the check for a large
  value (bsc#1057536)

It also includes various fixes for integer overflows and too-large bit
shifts that didn’t receive a CVE.

These non-security issues were fixed:

• Unconditionalize celt, ass, openjpeg, webp, netcdf, libva, vdpau.
• Build unconditionally with lame and twolame
• Enabled cuda and cuvid for unrestricted build.
• Add additional checks to ensure MPEG is off