Don A. Bailey of Lab Mouse Security reported an integer overflow issue in various implementations of LZO (Lempel–Ziv–Oberhumer) and LZ4 compression algorithms. The issue is in the handling of "literal runs" during decompression, and can lead to application crash and, possibly, code execution.
This bug is for LZ4 and LZ4 copy embedded in the Linux kernel (as of version 3.11).
This issue can not be triggered on 64bit systems today, as it would require input of the size that is beyond capabilities of modern computers. On 32bit systems, this can only affect applications using sufficiently large decompression blocks (16mb+).
Created lz4 tracking bugs for this issue:
Affects: fedora-all [bug 1113869]
Affects: epel-all [bug 1113870]
This issue is public:
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 1113884]
Not vulnerable. This issue does not affect the kernel packages as shipped with Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise Linux MRG 2.
I believe this is fixed upstream with:
Which has been backported to the stable kernels with commits:
Blog posts from Don A. Bailey, the original reporter of this issue:
Reporter's security reports for both LZ4 upstream, and embedded copy as used in the Linux kernel:
Feedback from the LZ4 upstream, which indicates there are no application known to be affected by this flaw, as the issue is only exploitable when application uses large decompression blocks (16mb+). LZ4 file format does not allow blocks of such size.
LZ4 upstream bugs report, an independent report from Ludwig Strigeus, which pre-dates Don A. Bailey's report:
LZ4 upstream fix:
The above fix was applied to LZ4 upstream repository with other changes as part of this commit:
Test case from the above LZ4 upstream bug report: