Bug 1954559 (CVE-2021-3520) - CVE-2021-3520 lz4: memory corruption due to an integer overflow bug caused by memmove argument
Summary: CVE-2021-3520 lz4: memory corruption due to an integer overflow bug caused by...
Alias: CVE-2021-3520
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1959427 1959429 1959430 1959431 1954560 1957036 1957037 1957038 1959428 1959432 1959433 1959434 1959435 1959437 1959438 1959439 1959440 1959441 1959442
Blocks: 1935389
TreeView+ depends on / blocked
Reported: 2021-04-28 11:36 UTC by Dhananjay Arunesh
Modified: 2022-07-19 13:40 UTC (History)
44 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
There's a flaw in lz4. An attacker who submits a crafted file to an application linked with lz4 may be able to trigger an integer overflow, leading to calling of memmove() on a negative size argument, causing an out-of-bounds write and/or a crash. The greatest impact of this flaw is to availability, with some potential impact to confidentiality and integrity as well.
Clone Of:
Last Closed: 2021-06-29 16:41:14 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:2575 0 None None None 2021-06-29 16:31:00 UTC
Red Hat Product Errata RHSA-2022:1345 0 None None None 2022-04-13 11:27:06 UTC
Red Hat Product Errata RHSA-2022:5606 0 None None None 2022-07-19 13:40:24 UTC

Description Dhananjay Arunesh 2021-04-28 11:36:37 UTC
A vulnerability was found in lz4, where a potential memory corruption due to an integer overflow bug which caused one of the memmove arguments to become negative. Depending on how the library was compiled this will hit an assert() inside the library and dump core, leaving a 4GB core file, or it wil go into libc and crash inside the memmove() function.


Comment 1 Dhananjay Arunesh 2021-04-28 11:38:13 UTC
Created lz4 tracking bugs for this issue:

Affects: fedora-all [bug 1954560]

Comment 3 Todd Cullum 2021-05-04 21:48:33 UTC
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.

Comment 5 Todd Cullum 2021-05-04 22:06:09 UTC

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 .

Comment 6 Todd Cullum 2021-05-04 22:40:26 UTC
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.

Comment 11 errata-xmlrpc 2021-06-29 16:30:56 UTC
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

Comment 12 Product Security DevOps Team 2021-06-29 16:41:14 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Comment 13 errata-xmlrpc 2022-04-13 11:27:02 UTC
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

Comment 16 errata-xmlrpc 2022-07-19 13:40:22 UTC
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

Note You need to log in before you can comment on or make changes to this bug.