Bug 883949 (CVE-2014-4611)

Summary: VUL-0: CVE-2014-4611: kernel: integer overflow in lz4_uncompress
Product: [Novell Products] SUSE Security Incidents Reporter: Johannes Segitz <jsegitz>
Component: IncidentsAssignee: E-mail List <kernel-maintainers>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Major    
Priority: P3 - Medium CC: hare, jbeulich, jsegitz, meissner, mhocko, tiwai
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: lz4.patch
alternative tentative fix

Description Johannes Segitz 2014-06-24 08:12:50 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

Vulnerability Scope:
All versions of the Linux kernel (3x/2x) with LZ4 support (lib/lz4).

Functions Affected:

Criticality Reasoning
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.

Vulnerability Description
An integer overflow can occur when processing any variant of a "literal run"
in the lz4_uncompress function.

Vulnerability Resolution
The Linux kernel team has resolved this vulnerability.
Comment 1 Swamp Workflow Management 2014-06-24 22:00:40 UTC
bugbot adjusting priority
Comment 3 Jiri Kosina 2014-06-25 09:56:22 UTC
SLE12 has CONFIG_KERNEL_LZ4 turned off. SLE11-SP3 doesn't have LZ4.
Comment 4 Marcus Meissner 2014-06-25 12:41:30 UTC
Created attachment 596092 [details]

commit 206204a1162b995e2185275167b22468c00d6b36
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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" <donb@securitymouse.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Comment 6 Marcus Meissner 2014-06-27 07:59:32 UTC
This code was added in the 3.11 kernel, older versions like in SUSE Linux Enterprise 11 are not affected.
Comment 8 Takashi Iwai 2014-07-31 14:26:54 UTC
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.
Comment 9 Michal Marek 2014-08-15 13:50:30 UTC
Does not affect any of the shipped kernels.
Comment 10 Michal Marek 2014-08-15 14:05:22 UTC
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.
Comment 11 Takashi Iwai 2014-08-15 15:07:20 UTC
Oops, right, it was a wrong option.
Applied and pushed to openSUSE-13.1 branch now.

SLE12 has already the fix through stable tree.
Comment 12 Jan Beulich 2014-08-15 21:42:33 UTC
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.
Comment 13 Marcus Meissner 2014-08-21 12:20:50 UTC
reopen due to last comment
Comment 14 Takashi Iwai 2014-08-21 12:40:43 UTC
Then I pass this bug to Jan, who can handle this obviously at best.
Comment 15 Jan Beulich 2014-08-22 07:30:48 UTC
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.
Comment 16 Marcus Meissner 2014-08-22 07:46:01 UTC
FWIW, i mailed your comment to security@kernel.org and oss-security. no reply there yet
Comment 17 Takashi Iwai 2014-11-13 13:12:20 UTC
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.
Comment 18 Jan Beulich 2014-11-13 14:30:42 UTC
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.
Comment 19 Takashi Iwai 2014-11-13 15:26:00 UTC
OK, it should be notified to suecurity team that it's not covered yet.
Comment 20 Johannes Segitz 2014-11-17 15:44:12 UTC
(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?
Comment 21 Takashi Iwai 2014-11-17 21:28:17 UTC
(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...
Comment 22 Swamp Workflow Management 2014-12-21 12:07:44 UTC
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
Sources used:
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-, 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
Comment 23 Hannes Reinecke 2015-12-16 14:07:11 UTC
Update has been released. Closing.