|
| 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