This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora EPEL. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, use the bodhi submission link noted in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the Bodhi notes field when available. NOTE: this issue affects multiple supported versions of Fedora EPEL. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. [bug automatically created by: add-tracking-bugs]
Use the following update submission link to create the Bodhi request for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. IMPORTANT: ensure that the "Close bugs when update is stable" option remains checked. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=1112436,1113870
+-- On Fri, 27 Jun 2014 Yann Collet wrote --+ |Hi Prasad | |Nope, latest lz4 release is not affected. | | |Moreover, even the linux kernel implementation is safe, for now. To trigger |the risk, the program calling the lz4 linux kernel implementation must feed |the decoder with blocks of more than 8 MB. None of them is doing that right |now, so it's not exploitable. | |However, it's true that, in the future, maybe one program may wander into |this area. So it's a good thing to update the LZ4 implementation today, |before the risk get potentially exposed by a yet unknown future program. | | |I feel this version of the story should be more widely answered. The current |risk has been overblown. If you have some way to answer to the sec-list |article you linked to, could you please make it known ? In the meantime, I'm |in contact with Greg k-h, to make sure the linux kernel implementation will |get fixed for the next Linux release. | |Best regards | -> http://www.openwall.com/lists/oss-security/2014/06/27/9