Publish GHSA-vvp9-7p8x-rfvv

Author: advisory-database[bot]

advisories/github-reviewed/2026/03/GHSA-vvp9-7p8x-rfvv/GHSA-vvp9-7p8x-rfvv.json

@@ -1,11 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-vvp9-7p8x-rfvv",
-  "modified": "2026-03-16T20:48:08Z",
+  "modified": "2026-03-19T18:42:05Z",
   "published": "2026-03-16T20:48:08Z",
-  "aliases": [],
+  "aliases": [
+    "CVE-2026-32829"
+  ],
   "summary": "lz4_flex's decompression can leak information from uninitialized memory or reused output buffer",
-  "details": "### Summary\nDecompressing invalid LZ4 data can leak data from uninitialized memory, or can leak content from previous decompression operations when reusing an output buffer.\n\n### Details\nThe LZ4 block format defines a \"match copy operation\" which duplicates previously written data or data from the user-supplied dict. The position of that data is defined by an _offset_. The data is copied within the output buffer from the _offset_ to the current output position.\nHowever, lz4_flex did not properly detect invalid and out-of-bounds _offset_ values properly, causing it to copy uninitialized data from the output buffer.\n\nOnly the block based API functions are affected: \n`lz4_flex::block::{decompress_into, decompress_into_with_dict}`\n\nAll `frame` APIs are _not_ affected.\n\nThere are two affected use cases:\n- decompressing LZ4 data with the `unsafe` implementation (`safe-decode` feature flag disabled, which is enabled by default):\ncan leak content of uninitialized memory as decompressed result\n- decompressing LZ4 data into a reused, user-supplied `output` buffer (affects the `safe-decode` feature as well):\ncan leak the previous contents of the output buffer as decompressed result\n\n### Impact\nLeakage of data from uninitialized memory or content from previous decompression operations, possibly revealing sensitive information and secrets.\n\n### Mitigation\nlz4_flex 0.12.1 and 0.11.6 fixes this issue without requiring changes in user code.\n\nIf you cannot upgrade, you can mitigate this vulnerability by zeroing the output buffer before calling `block::decompress_into` or  `block::decompress_into_with_dict` (only block based API is affected, frame API is not affected). Additionally the the `safe-decode` feature flag should be enabled.",
+  "details": "### Summary\nDecompressing invalid LZ4 data can leak data from uninitialized memory, or can leak content from previous decompression operations when reusing an output buffer.\n\n### Details\nThe LZ4 block format defines a \"match copy operation\" which duplicates previously written data or data from the user-supplied dict. The position of that data is defined by an _offset_. The data is copied within the output buffer from the _offset_ to the current output position.\nHowever, lz4_flex did not properly detect invalid and out-of-bounds _offset_ values properly, causing it to copy uninitialized data from the output buffer.\n\nOnly the block based API functions are affected: \n`lz4_flex::block::{decompress_into, decompress_into_with_dict}`\n\nWhen safe-decode is disabled _additionally_ these functions are affected\n`lz4_flex::block::{decompress, decompress_with_dict, decompress_size_prepended, decompress_size_prepended_with_dict}`\n\nAll `frame` APIs are _not_ affected.\n\nThere are two affected use cases:\n- decompressing LZ4 data with the `unsafe` implementation (`safe-decode` feature flag disabled, which is enabled by default):\ncan leak content of uninitialized memory as decompressed result\n- decompressing LZ4 data into a reused, user-supplied `output` buffer (affects the `safe-decode` feature as well):\ncan leak the previous contents of the output buffer as decompressed result\n\n### Impact\nLeakage of data from uninitialized memory or content from previous decompression operations, possibly revealing sensitive information and secrets.\n\n### Mitigation\nlz4_flex 0.12.1 and 0.11.6 fixes this issue without requiring changes in user code.\n\nIf you cannot upgrade, you can mitigate this vulnerability by zeroing the output buffer before calling `block::decompress_into` or  `block::decompress_into_with_dict` (only block based API is affected, frame API is not affected). Additionally the the `safe-decode` feature flag should be enabled.",
   "severity": [
     {
       "type": "CVSS_V4",
@@ -64,6 +66,10 @@
     {
       "type": "PACKAGE",
       "url": "https://github.com/PSeitz/lz4_flex"
+    },
+    {
+      "type": "WEB",
+      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0041.html"
     }
   ],
   "database_specific": {