From ${URL} : Description Multiple vulnerabilities have been reported in FFmpeg, where some have an unknown impact and others can be exploited by malicious people to cause a DoS (Denial of Service). 1) Two errors within the "jpeg2000_decode_tile()" function (libavcodec/jpeg2000dec.c) can be exploited to cause a crash. 2) An error within the "get_cod()" function (libavcodec/jpeg2000dec.c) when handling components of MCT can be exploited to cause an out of bounds memory access. 3) An error within the "smvjpeg_decode_frame()" function (libavcodec/smvjpegdec.c) when extracting a picture can be exploited to cause a crash. 4) An error within the "tiff_unpack_strip()" function (libavcodec/tiff.c) can be exploited to cause an out of bounds memory access. 5) An error within the "smvjpeg_decode_init()" function (libavcodec/smvjpegdec.c) can be exploited to cause an out of bounds memory access. 6) An error within the "ff_jpeg2000_init_component()" function (libavcodec/jpeg2000.c) can be exploited to cause an out of bounds memory access. 7) A division by zero error within the "get_siz()" function (libavcodec/jpeg2000dec.c) can be exploited to cause a crash. 8) An error within the "get_qcc()" function (libavcodec/jpeg2000dec.c) can be exploited to cause an out of bounds memory access. 9) An error within JPEG 2000 image decoder (libavcodec/jpeg2000dec.c) can be exploited to cause an out of bounds memory access. 10) An error within the "jpeg2000_read_main_headers()" function (libavcodec/jpeg2000dec.c) can be exploited to cause an out of bounds memory access. Solution Fixed in the GIT repository. Provided and/or discovered by The vendor credits Mateusz "j00ru" Jurczyk and Gynvael Coldwind. Original Advisory http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=6e9bfc19bd7be2b28258ca93d706cb67ed482c65;hp=16f3102f41031f70a24cf25836b1b7ab972c1265 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=bbc19010edfdb1b2e248a24894c5ec77960bbfc3;hp=702c1bf240f255d9afe2c3dbf2f07d7fbdc2ffc7 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c59ce1c98e5fdcd3d00fa4980ec8516eb9cad2c4;hp=b28851a1d688f2c650977ea73c1d775417a0bd0e http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c51654fbc023f22feabee68a858a1a33e12ed9f6;hp=a28f4fd1ea45821100032403ebdac1c164b10007 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b26bcd08e670b90740f7253f21adddafb9d8c478;hp=c51654fbc023f22feabee68a858a1a33e12ed9f6 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c49d94487c6135325930cbc4a8cd96d38ef6653e;hp=75b9fb27f516f9db7995ab2c2abb83e25cae5813 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=21d0f75f29ca97b2ca31bd4451f488163a27e24f;hp=c49d94487c6135325930cbc4a8cd96d38ef6653e http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=bce2ed55596a603b0dd35e000e064b9a40eee542;hp=369684f1092427a3cfa1a62b43f2952a5554061d http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=9c2216976907336dfae0e8e38a4d70ca2465a92c;hp=999ccd2d0a43640921088578f138c874f6cc0f8a http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=467e7a8f26e54c300ba494bf00033fec1078fa45;hp=0ea135613788ef69ee4f52afb520a169e6da6b9e @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
(In reply to Agostino Sarubbo from comment #0) the jpeg2000 and smvjpeg native decoders were never released and are currently only in ffmpeg master, hence a non-issue for us. > 4) An error within the "tiff_unpack_strip()" function > (libavcodec/tiff.c) can be exploited to cause an out of bounds memory > access. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=9c2216976907336dfae0e8e38a4d70ca2465a92c this is only libav people catching up and causing confusion by not giving proper credits: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=fefc65675eb5def2a34787cffea53c88e956cca1 this is fixed since a long time in the 1.0 branch (and hence 1.0.7)
Need sparc stabilized to drop 1.0.6, sparc team: please stable media-video/ffmpeg-1.0.7. Also, is ffmpeg-0.10.7.ebuild affected by this? If so, please also CC alpha for keyword & stable.
(In reply to Chris Reffett from comment #2) yes and this is handled in bug #473302 ...
Adding to existing GLSA draft.
This issue was resolved and addressed in GLSA 201310-12 at http://security.gentoo.org/glsa/glsa-201310-12.xml by GLSA coordinator Sean Amoss (ackle).