HistoryEditJSON (OSV)

RUSTSEC-2026-0041

Decompressing invalid data can leak information from uninitialized memory or reused output buffer

Reported
Issued
Package
lz4_flex (crates.io)
Type
Vulnerability
Categories
Keywords
#lz4 #decompression #information-disclosure #uninitialized-memory
Aliases
CVSS Score
8.2 HIGH
CVSS Details
Attack Complexity
Low
Attack Requirements
Present
Attack Vector
Network
Privileges Required
None
Availability Impact to the Subsequent System
None
Confidentiality Impact to the Subsequent System
None
Integrity Impact to the Subsequent System
None
User Interaction
None
Availability Impact to the Vulnerable System
None
Confidentiality Impact to the Vulnerable System
High
Integrity Impact to the Vulnerable System
None
CVSS Vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Patched
  • >=0.11.6, <0.12.0
  • >=0.12.1
Affected Functions
Version
lz4_flex::block::decompress_into
  • <=0.11.5
  • =0.12.0
lz4_flex::block::decompress_into_with_dict
  • <=0.11.5
  • =0.12.0

Description

Decompressing invalid LZ4 data with the block API can leak data from uninitialized memory, or leak content from previous decompression operations when reusing an output buffer.

The LZ4 block format defines a "match copy operation" which duplicates previously written data or data from a user-supplied dict. The position of that data is defined by an offset. lz4_flex did not properly validate offset values, causing it to copy data from outside the initialized portion of the output buffer.

Two scenarios are affected:

Only the block-based API is affected: lz4_flex::block::decompress_into and lz4_flex::block::decompress_into_with_dict. All frame APIs are unaffected.

The flaw was corrected in versions 0.11.6 and 0.12.1 by properly validating offset values during decompression.

If upgrading is not possible, the issue can be mitigated by zeroing the output buffer before each call to the affected functions and enabling the safe-decode feature flag.

Advisory available under CC0-1.0 license.