LZ4 before 1.9.2 has a heap-based buffer overflow in LZ4_write32 (related to LZ4_compress_destSize), affecting applications that call LZ4_compress_fast with a large input. (This issue can also lead to data corruption.) NOTE: the vendor states "only a few specific / uncommon usages of the API are at risk."
Created lz4 tracking bugs for this issue:
Affects: epel-6 [bug 1765318]
Affects: fedora-all [bug 1765317]
Red Hat OpenStack Platform 10 packages an older version of lz4 that has the flawed code. However, because OpenStack has been using RHEL's updated lz4 version since RHEL7.5 started to include it, Red Hat is not currently updating the OpenStack lz4 package.
As per upstream:
Actually, in most systems, including the lz4 frame format and API, the bug is just out of reach. That's what makes it so difficult to discover, and since it also requires multiple uncommon constraints on the encoder side, which are out of direct control from an external actor (in contrast with the payload), this bug is rarely "reachable", making it a poor exploit vector.
Note that the CLI is immune to this bug, as it does not present the required constraints to be exposed, hence the suggested reproduction command lz4 -1 -l outfile should not work. The CLI is considered safe, for all versions. It's only a few specific / uncommon usages of the API which are at risk.
We invite all users of LZ4 to upgrade to v1.9.2, to reduce exposure to risks, but the risk is low : specifically, the lz4 CLI is safe, and all "common" usages of the API (covered by the documentation) are safe too.