I've received an answer from Don Bailey. He blames the situation on a lack of communication. OK. In an attempt to bring the discussion to a more neutral level, this post is dedicated at providing a hopefully clear, concise and factual description of the situation. I hope it will help the reader to properly assess the risk level.
- There was a vulnerability, it was fully described by Ludwig Strigeus and tracked for correction on the LZ4 issue board
- The vulnerability is fixed. Update is recommended for 32-bits applications
- The vulnerability requires uncommon conditions to be exploitable :
- Input data supplied by untrusted source
- Large block sizes, preferably ~16MB (beyond LZ4 file format specification)
- 32-bits applications only
- These conditions are not met by currently known programs using LZ4
- For a list of them, get to the LZ4 homepage. It's correct to state that some yet unknown application may match these conditions. That's why the reference version has been fixed
- Edit :
One use case has been found, involving custom scripts to receive untrusted data from external sources using a Python version of LZ4 while not enforcing block size limits.The targeted Python version was using an unprotected version of the decoder. Conclusion remains the same : the Python version has been updated to cover such situation, and is a recommended upgrade
- The Linux Kernel version, which is different and supplied by LG, has this vulnerability too
- Linux Kernel programs (which are the only ones to access kernel functions) do not match the conditions that would make it exploitable
- The Linux Kernel version is nonetheless being fixed too, to avoid any future risk for future versions of the kernel
Hope it helps.