rustsec-2026-0344
debian_rustsecA crafted `.zst` input under 128 KB can force `ruzstd` to allocate several gigabytes at once, crashing the process with an out-of-memory condition. Since `ruzstd` is a decoder for untrusted input, a single small file is enough to take down anything decoding it. The compressed size of a block was capped at 128 KB, but a compressed block's **decompressed** size was never checked against `Block_Maximum_Size = min(Window_Size, 128 KiB)` (RFC 8878). In `execute_sequences` the output was built with no running bound and no flush between blocks, so one block could expand to gigabytes — bypassing both the configured window-size limit and the block-by-block streaming that would otherwise release memory. (A related `u32` counter overflow on such a block caused an additional panic.) This is a denial of service only; memory access stays in bounds (no corruption, no RCE). `ruzstd` is also built as a dependency of the Rust standard library via `rustc-dep-of-std`; in the toolchain it is used only to load zstd-compressed debug symbols, so the toolchain-side impact is limited. **Fixed in 0.9.1** (commit `d3907c9`), which enforces the per-block output bound. Upgrade to `ruzstd >= 0.9.1`.
- Published
- unknown
- Last Modified
- unknown
CVSS details not available.
No product information available.
No references available.
No linked vulnerabilities found.
{
"aliases": [],
"categories": [
"denial-of-service"
],
"crate": "ruzstd",
"cves": [],
"cvss": 0.0,
"database_specific": {
"severity": "high"
},
"date": "2026-10-11",
"deb_packages": [
{
"crate_name": "czkawka-cli",
"deb_name": "czkawka-cli",
"version": "12.0.2-2"
},
{
"crate_name": "czkawka-gui",
"deb_name": "czkawka-gui",
"version": "12.0.2-1"
},
{
"crate_name": null,
"deb_name": "dwarf2sources",
"version": "0.2.6-1+b2"
},
{
"crate_name": "elfx86exts",
"deb_name": "elfx86exts",
"version": "0.6.2-5"
},
{
"crate_name": "feluda",
"deb_name": "feluda",
"version": "1.17.0-2"
},
{
"crate_name": "ruzstd",
"deb_name": "librust-ruzstd-dev",
"version": "0.8.3-2"
},
{
"crate_name": "repro-env",
"deb_name": "repro-env",
"version": "0.4.4+ds-1"
},
{
"crate_name": "samply",
"deb_name": "samply",
"version": "0.13.1-1+b2"
},
{
"crate_name": "xh",
"deb_name": "xh",
"version": "0.26.3-1"
}
],
"description": "A crafted `.zst` input under 128 KB can force `ruzstd` to allocate several gigabytes at once, crashing the process with an out-of-memory condition. Since `ruzstd` is a decoder for untrusted input, a single small file is enough to take down anything decoding it.\n\nThe compressed size of a block was capped at 128 KB, but a compressed block's **decompressed** size was never checked against `Block_Maximum_Size = min(Window_Size, 128 KiB)` (RFC 8878). In `execute_sequences` the output was built with no running bound and no flush between blocks, so one block could expand to gigabytes — bypassing both the configured window-size limit and the block-by-block streaming that would otherwise release memory. (A related `u32` counter overflow on such a block caused an additional panic.)\n\nThis is a denial of service only; memory access stays in bounds (no corruption, no RCE).\n\n`ruzstd` is also built as a dependency of the Rust standard library via `rustc-dep-of-std`; in the toolchain it is used only to load zstd-compressed debug symbols, so the toolchain-side impact is limited.\n\n**Fixed in 0.9.1** (commit `d3907c9`), which enforces the per-block output bound. Upgrade to `ruzstd >= 0.9.1`.",
"id": "RUSTSEC-2026-0344",
"keywords": [
"zstd",
"decompression-bomb",
"oom"
],
"patched_versions": [
">=0.9.1"
],
"source": "debian_rustsec",
"title": "Decompression bomb in `ruzstd`: a tiny input can exhaust memory (OOM)",
"url": "https://github.com/KillingSpark/zstd-rs/commit/d3907c960ca4a1aa44cc38340137c5679dd98f5a"
}