Skip to content

Commit 750e74e

Browse files
PSeitzdjc
authored andcommitted
Add RUSTSEC for lz4_flex (CVE-2026-32829)
1 parent 3184813 commit 750e74e

File tree

1 file changed

+43
-0
lines changed

1 file changed

+43
-0
lines changed
Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
```toml
2+
[advisory]
3+
id = "RUSTSEC-0000-0000"
4+
package = "lz4_flex"
5+
date = "2026-03-17"
6+
categories = ["memory-exposure"]
7+
keywords = ["lz4", "decompression", "information-disclosure", "uninitialized-memory"]
8+
aliases = ["CVE-2026-32829", "GHSA-vvp9-7p8x-rfvv"]
9+
cvss = "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"
10+
11+
[affected.functions]
12+
"lz4_flex::block::decompress_into" = ["<= 0.11.5", "= 0.12.0"]
13+
"lz4_flex::block::decompress_into_with_dict" = ["<= 0.11.5", "= 0.12.0"]
14+
15+
[versions]
16+
patched = [">= 0.11.6, < 0.12.0", ">= 0.12.1"]
17+
```
18+
19+
# Decompressing invalid data can leak information from uninitialized memory or reused output buffer
20+
21+
Decompressing invalid LZ4 data with the block API can leak data from uninitialized memory,
22+
or leak content from previous decompression operations when reusing an output buffer.
23+
24+
The LZ4 block format defines a "match copy operation" which duplicates previously written
25+
data or data from a user-supplied dict. The position of that data is defined by an _offset_.
26+
`lz4_flex` did not properly validate _offset_ values, causing it to copy data from outside
27+
the initialized portion of the output buffer.
28+
29+
Two scenarios are affected:
30+
31+
- Decompressing with the `unsafe` implementation (`safe-decode` feature flag disabled, which
32+
is the default): can leak content of uninitialized memory as part of the decompressed result.
33+
- Decompressing into a reused, user-supplied output buffer (also affects `safe-decode`): can
34+
leak the previous contents of the output buffer as part of the decompressed result.
35+
36+
Only the block-based API is affected: `lz4_flex::block::decompress_into` and
37+
`lz4_flex::block::decompress_into_with_dict`. All frame APIs are unaffected.
38+
39+
The flaw was corrected in versions 0.11.6 and 0.12.1 by properly validating offset values
40+
during decompression.
41+
42+
If upgrading is not possible, the issue can be mitigated by zeroing the output buffer before
43+
each call to the affected functions and enabling the `safe-decode` feature flag.

0 commit comments

Comments
 (0)