From ${URL} : Description Multiple vulnerabilities have been reported in FFmpeg, which can be exploited by malicious people to cause a DoS (Denial of Service) and compromise an application using the library. 1) An error within the "decode_subframe()" function (libavcodec/wmaprodec.c) can be exploited to cause a buffer overflow. 2) An error within the "save_bits()" function (libavcodec/wmaprodec.c) when saving packets can be exploited to cause a buffer overflow. 3) An error within the "ff_mjpeg_decode_frame()" function (libavcodec/mjpegdec.c) can be exploited to cause a buffer overflow. 4) A NULL pointer dereference error exists within the "ivi_process_empty_tile()" function (libavcodec/ivi_common.c) and can be exploited to cause a crash. 5) An error within the "decode_band()" function (libavcodec/ivi_common.c) when handling tile data can be exploited to corrupt memory. 6) A NULL pointer dereference error exists within the "jpeg2000_decode_tile()" function (libavcodec/jpeg2000dec.c) and can be exploited to cause a crash. 7) An out-of-bounds read error exists within the "jpeg2000_read_main_headers()" function (libavcodec/jpeg2000dec.c) when handling SOD markers and can be exploited to cause a crash. 8) An out-of-bounds read error exists within the "ff_jpeg2000_init_component()" function (libavcodec/jpeg2000.c) and can be exploited to cause a crash. 9) An out-of-bounds read error exists within the "get_cod()" function (libavcodec/jpeg2000dec.c) and can be exploited to cause a crash. 10) An out-of-bounds read error within the get_coc()" function (libavcodec/jpeg2000dec.c) can be exploited to cause a crash. 11) An out-of-bounds read error within the "get_qcc()" function (libavcodec/jpeg2000dec.c) can be exploited to cause a crash. 12) An out-of-bounds read error within the "jpeg2000_read_main_headers()" function (libavcodec/jpeg2000dec.c) can be exploited to cause a crash. 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=commit;h=38229362529ed1619d8ebcc81ecde85b23b45895 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e30b068ef79f604ff439418da07f7e2efd01d4ea http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6765ee7b9cba46818a45b051438b2552f0a1b70a http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b36e1893ef3430f039c1eaddeedcbb378f9c4444 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=7388c0c58601477db076e2e74e8b11f8a644384a http://git.videolan.org/?p=ffmpeg.git;a=commit;h=95a57d26d8653d21f0dab1aff3558ee944853dbf http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b564784a207b1395d2b5a41e580539df04651096 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=78962d3df49afe5011b572656ecfe940bd5fbf2e http://git.videolan.org/?p=ffmpeg.git;a=commit;h=cf04af2086be105ff86088357b83d672d38417d9 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=eae63e3c156f784ee0612422f0c95131ea913c14 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=fd54dd028bc9f7bfb80ebf823a533dc84b73f936 @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.
Not clear which branches this affects, will see when upstream pushes to the release branches.
please check the git log of the relevant files. it is likely it is just libav people catching up, that it was fixed long ago in ffmpeg, and this appears in ffmpeg.git history because of the merges.
All jpeg2k are backports if they are coming from Michael Niedermayer (as you could guess), the rest should not.
(In reply to Luca Barbato from comment #3) > All jpeg2k are backports if they are coming from Michael Niedermayer (as you > could guess), the rest should not. not sure if jpeg2k stuff affects 1.0 branch (it has the old jpeg j2k*.c code) not sure about the others either, these two look similar: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=38229362529ed1619d8ebcc81ecde85b23b45895 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b21ba20cc83c80fe56192fee3626a8087f37d806 didnt check the rest
It looks like the ones that may have affected us, only affected the 0.10 branch and not 1.0. 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).