Bug 1954559 (CVE-2021-3520)

Created lz4 tracking bugs for this issue:

Affects: fedora-all [bug 1954560]

Upstream patch: https://github.com/lz4/lz4/pull/972/commits/8301a21773ef61656225e264f4f06ae14462bca7

The lz4 binary itself catches the problem when it parses the header, but it seems not all library consumers do and therefore LZ4_decompress_generic() was patched.

Statement:

This flaw is out of support scope for Red Hat Enterprise Linux 7. To learn more about Red Hat Enterprise Linux support life cycles, please see https://access.redhat.com/support/policy/updates/errata .

Flaw summary:

In the LZ4_decompress_generic() routine, outputSize is retrieved from the lz4 file and is an integer. A code path allows outputSize to influence the value of `length` via `oend` in the call to memmove(op, ip, length). A crafted file can cause outputSize to be a negative value, and since length is interpreted by memmove() as a size_t, it can be an extremely large, out-of-bounds value. The upstream patch checks to ensure that outputSize is not less than 0 at the beginning of the routine.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:2575 https://access.redhat.com/errata/RHSA-2021:2575

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2021-3520

This issue has been addressed in the following products:

  Red Hat AMQ Streams 2.1.0

Via RHSA-2022:1345 https://access.redhat.com/errata/RHSA-2022:1345

This issue has been addressed in the following products:

  RHINT Camel-Q 2.7

Via RHSA-2022:5606 https://access.redhat.com/errata/RHSA-2022:5606

This issue has been addressed in the following products:

  RHAF Camel-K 1.8

Via RHSA-2022:6407 https://access.redhat.com/errata/RHSA-2022:6407

There are a nb of incorrect statements in this thread, and I want to provide a counterpoint for anyone willing to take the time to understand this topic.

Probably the most incorrect statement is contained in this assertion : 
"A crafted file can cause outputSize to be a negative value"

Absolutely not.

The #972 patch is completely unrelated to the payload ingested by the `LZ4_decompress*()` function, meaning there is no attack possible through a "crafted file" vector.

What https://github.com/lz4/lz4/pull/972 covers is an _incorrect usage of the interface_ , by extending the contract of this interface.

The incorrect usage is providing an incorrect parameter as output buffer size, aka a wrong buffer size.
Providing a wrong buffer size is considered UB territory, same class as providing a wrong pointer.
That being said, in #972 the contract has been extended to detect and return a specific case when the size parameter is so completely wrong that it is negative.
Note that this contract extension does not cover situations where the size is incorrect (too large) but still positive.

And neither should it try to.
All interface contracts have limits, and providing obviously bogus parameters should not be classified as a CVE for the called function.
It might be a CVE, but then for the _caller_ of the function.

It follows that any implementation that correctly invokes the LZ4 decoder interface was never at risk.

Other fixable statements seen in this thread : 
- "a potential memory corruption due to an integer overflow" : it's not an integer overflow, it's a careless cast to `int` on the _user side_ of the code base (before invoking LZ4_decompress*() function)
- "In the LZ4_decompress_generic() routine, outputSize is retrieved from the lz4 file" : LZ4_decompress*() never "retrieves" any size, it has no <stdio.h> dependency, it's unaware of the concept of file. What it does is receive an `outputSize` parameter. This parameter is controlled by the caller.

Not mentioned in the thread, but probably worth mentioning : 
In the initial issue, the issuer illustrates the issue with this example : "If the decompressed size is big enough, e.g. 0xff000000-0xffffffff".
The reference lz4 implementation publishes a _maximum block size_ as part of its interface, and is documented as not supporting single blocks larger than this maximum.
This maximum size is set at 0x7E000000 (https://github.com/lz4/lz4/blob/dev/lib/lz4.h#L212).
Hence, the examples are way out of range of the library contract.

PS : I'm not aware of, or don't know about, any process to "declassify" a CVE, so these comments are mostly provided for context.