Bugzilla – Bug 883949
VUL-0: CVE-2014-4611: kernel: integer overflow in lz4_uncompress
Last modified: 2015-12-16 14:07:11 UTC
CVE-2014-4611. No CRD given but will probably go public soon since it leaked.
Report ID: LMS-2014-06-16-5
Report Code Name: LAZARUS.5
Researcher Name: Don A. Bailey
All versions of the Linux kernel (3x/2x) with LZ4 support (lib/lz4).
Due to the design of the algorithm, an attacker can specify any desired
offset to a write pointer. The attacker can instrument the write in such
a way as to only write four bytes at a specified offset. Subsequent code
will allow the attacker to escape from the decompression algorithm without
further memory corruption. This may allow the attacker to overwrite
critical structures in memory that affect flow of execution.
An integer overflow can occur when processing any variant of a "literal run"
in the lz4_uncompress function.
The Linux kernel team has resolved this vulnerability.
bugbot adjusting priority
SLE12 has CONFIG_KERNEL_LZ4 turned off. SLE11-SP3 doesn't have LZ4.
Created attachment 596092 [details]
Author: Greg Kroah-Hartman <email@example.com>
Date: Fri Jun 20 22:01:41 2014 -0700
lz4: ensure length does not wrap
Given some pathologically compressed data, lz4 could possibly decide to
wrap a few internal variables, causing unknown things to happen. Catch
this before the wrapping happens and abort the decompression.
Reported-by: "Don A. Bailey" <firstname.lastname@example.org>
Cc: stable <email@example.com>
Signed-off-by: Greg Kroah-Hartman <firstname.lastname@example.org>
This code was added in the 3.11 kernel, older versions like in SUSE Linux Enterprise 11 are not affected.
CONFIG_KERNEL_LZ4 is disabled in openSUSE 13.1 kernels, too. I guess we can close this as it doesn't hit to any released kernels.
I can still backport it although it's not used, if preferred.
Does not affect any of the shipped kernels.
Actually, openSUSE-13.1 has CONFIG_LZ4_DECOMPRESS=y and CONFIG_CRYPTO_LZ4=m. CONFIG_KERNEL_LZ4 is the wrong option to look at, as it only selects the kernel image compression algorithm.
SLE12's s390x/zfcpdump also has CONFIG_LZ4_DECOMPRESS=y, but it's unclear whether the there is any interface exposing the decompressor, besides possibly decompressing the (trusted) initrd.
Oops, right, it was a wrong option.
Applied and pushed to openSUSE-13.1 branch now.
SLE12 has already the fix through stable tree.
Except that it has been determined quite some time ago that all three fixes having gone in upstream so far don't really fix anything. I posted a patch that I think actually addresses the issue (https://lkml.org/lkml/2014/7/4/288), but till now no-one cared to comment on it, apply it, or point out what's still wrong, despite the ping 3 weeks later (https://lkml.org/lkml/2014/7/25/23). It was - instead of the insufficient Linux ones - in fact meanwhile applied to the Xen clone of that code.
reopen due to last comment
Then I pass this bug to Jan, who can handle this obviously at best.
No, sorry, I'm not going to waste my time on trying to get replies out of kernel people ignoring my patches. The fix obviously needs to be accepted upstream first (or the kernel team has to decide whether to ignore that rule here), and as said above I did already more than I think I should have done in that direction. I very much think that fixing kernel security issues is something that the kernel team should be doing, the more that it's process issues we're dealing with here and the technical part of it was already done.
FWIW, i mailed your comment to email@example.com and oss-security. no reply there yet
There are two more fixes landed in the upstream:
lz4: fix another possible overrun
lz4: add overrun checks to lz4_uncompress_unknownoutputsize()
The latter one seems addressing Jan's report.
I backported them to openSUSE-13.1 branch now.
SLE12 and openSUSE-13.2 already contain both fixes.
So, now fixed in all branches.
Created attachment 613522 [details]
alternative tentative fix
No. Here is the patch that I had sent upstream without ever getting any feedback from Greg or whoever ought to be looking at it. It was sent against 3.16-rc3, but since the code it applies to didn't change since then, it didn't need any updating so far.
OK, it should be notified to suecurity team that it's not covered yet.
(In reply to Takashi Iwai from comment #19)
Thanks. Do I understand it correctly that we won't include the patch until it gets accepted upstream? If so, why not?
(In reply to Johannes Segitz from comment #20)
> (In reply to Takashi Iwai from comment #19)
> Thanks. Do I understand it correctly that we won't include the patch until
> it gets accepted upstream? If so, why not?
Reviews from experts are mandatory for any patches...
openSUSE-SU-2014:1677-1: An update that solves 31 vulnerabilities and has 12 fixes is now available.
Category: security (important)
Bug References: 818966,835839,853040,856659,864375,865882,873790,875051,881008,882639,882804,883518,883724,883948,883949,884324,887046,887082,889173,890114,891689,892490,893429,896382,896385,896390,896391,896392,896689,897736,899785,900392,902346,902349,902351,904013,904700,905100,905744,907818,908163,909077,910251
CVE References: CVE-2013-2891,CVE-2013-2898,CVE-2014-0181,CVE-2014-0206,CVE-2014-1739,CVE-2014-3181,CVE-2014-3182,CVE-2014-3184,CVE-2014-3185,CVE-2014-3186,CVE-2014-3673,CVE-2014-3687,CVE-2014-3688,CVE-2014-4171,CVE-2014-4508,CVE-2014-4608,CVE-2014-4611,CVE-2014-4943,CVE-2014-5077,CVE-2014-5206,CVE-2014-5207,CVE-2014-5471,CVE-2014-5472,CVE-2014-6410,CVE-2014-7826,CVE-2014-7841,CVE-2014-7975,CVE-2014-8133,CVE-2014-8709,CVE-2014-9090,CVE-2014-9322
openSUSE 13.1 (src): cloop-2.639-11.16.1, crash-7.0.2-2.16.1, hdjmod-1.28-16.16.1, ipset-6.21.1-2.20.1, iscsitarget-18.104.22.168-13.16.1, kernel-docs-3.11.10-25.2, kernel-source-3.11.10-25.1, kernel-syms-3.11.10-25.1, ndiswrapper-1.58-16.1, pcfclock-0.44-258.16.1, vhba-kmp-20130607-2.17.1, virtualbox-4.2.18-2.21.1, xen-4.3.2_02-30.1, xtables-addons-2.3-2.16.1
Update has been released. Closing.