{"id":"RUSTSEC-2026-0344","aliases":[],"status":"published","title":"Decompression bomb in `ruzstd`: a tiny input can exhaust memory (OOM)","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 \u003e= 0.9.1`.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","from":"osv"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"published":"2026-10-11T12:00:00Z","modified":"2026-10-13T10:45:04Z","fixes":[{"ecosystem":"crates.io","package":"ruzstd","fixed_in":["0.9.1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"crates.io","package":"ruzstd","ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.9.1"}]}]}],"references":[{"url":"https://crates.io/crates/ruzstd","tags":["package"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2026-0344.html","tags":["advisory"]},{"url":"https://github.com/KillingSpark/zstd-rs/commit/d3907c960ca4a1aa44cc38340137c5679dd98f5a","tags":["web"]}],"sources":{"osv":[{"id":"RUSTSEC-2026-0344","title":"Decompression bomb in `ruzstd`: a tiny input can exhaust memory (OOM)","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 \u003e= 0.9.1`.","status":"published","published":"2026-10-11T12:00:00Z","modified":"2026-10-13T10:45:04.080993335Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:40.430679Z"}]}}