Denial of service because of stack overflow with malicious decompression input
A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash. ### Impact Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files. After stack overflows were found by [@inahga](https://github.com/inahga) with a fuzzer, we dove into the assembly, and found some cases where the stack grew ```asm .LBB109_326: mov rdi, rbx call zlib_rs::inflate::State::type_do jmp .LBB109_311 .LBB109_311: lea rsp, [rbp - 40] pop rbx pop r12 pop r13 pop r14 pop r15 pop rbp .cfi_def_cfa rsp, 8 ret ``` LLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do. So, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a
- Products
- zlib-rs
- Affected versions
- Not specified
- Fixed versions
- 0.4.0
- CVEs
- Not specified
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 30 Oct 2026, 08:44 UTC · Revision 1
Source evidence
Denial of service because of stack overflow with malicious decompression input
core-osv · Original sourcePublished 14 Nov 2024, 12:00 UTC
A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash. ### Impact Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files. After stack overflows were found by [@inahga](https://github.com/inahga) with a fuzzer, we dove into the assembly, and found some cases where the stack grew ```asm .LBB109_326: mov rdi, rbx call zlib_rs::inflate::State::type_do jmp .LBB109_311 .LBB109_311: lea rsp, [rbp - 40] pop rbx pop r12 pop r13 pop r14 pop r15 pop rbp .cfi_def_cfa rsp, 8 ret ``` LLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do. So, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a
osv:RUSTSEC-2024-0401
zlib-rs
Fixed versions: 0.4.0
Complete source record
{
"id": "96fcd0db6e6fa2a7b77f24676e8d119479f7813fa5d6b29511a7c0b027773b2c",
"url": "https://osv.dev/vulnerability/RUSTSEC-2024-0401",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Denial of service because of stack overflow with malicious decompression input",
"summary": "A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash. ### Impact Due to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files. After stack overflows were found by [@inahga](https://github.com/inahga) with a fuzzer, we dove into the assembly, and found some cases where the stack grew ```asm .LBB109_326: mov rdi, rbx call zlib_rs::inflate::State::type_do jmp .LBB109_311 .LBB109_311: lea rsp, [rbp - 40] pop rbx pop r12 pop r13 pop r14 pop r15 pop rbp .cfi_def_cfa rsp, 8 ret ``` LLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do. So, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a ",
"evidence": "osv:RUSTSEC-2024-0401",
"products": [
{
"name": {
"value": "zlib-rs",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "0.4.0",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "RUSTSEC-2024-0401",
"aliases": [
"GHSA-j3px-q95c-9683",
"RUSTSEC-2024-0401"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
}
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "0.4.0"
}
]
}
],
"package": {
"name": "zlib-rs",
"purl": "pkg:cargo/zlib-rs",
"ecosystem": "crates.io"
},
"database_specific": {
"cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"source": "https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2024-0401.json",
"categories": [
"denial-of-service"
],
"informational": null
},
"ecosystem_specific": {
"affects": {
"os": [],
"arch": [],
"functions": [
"zlib_rs::inflate::inflate"
]
},
"affected_functions": null
}
}
],
"modified": "2026-10-12T18:00:12.405715281Z",
"provider": "osv",
"references": [
"https://crates.io/crates/zlib-rs",
"https://rustsec.org/advisories/RUSTSEC-2024-0401.html",
"https://github.com/trifectatechfoundation/zlib-rs/pull/248"
],
"provider_metadata": {
"license": "CC0-1.0"
}
},
"related_cves": [],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 306431,
"published_at": "2024-11-14T12:00:00+00:00"
}