libz-rs-sys-cdylib
A zlib implementation in rust available as a C dynamic library and as a rust crate
View on Github
Activity
- Latest release
- 1mo ago
- Total releases
- 18
- Cadence
- ~28 days
- Last 12 months
- 11
Reach
- Stars
- 686
Details
- License
- Zlib
- First release
- Sep 05, 2024
| Version | Released | |
|---|---|---|
0.6.7
patch
| ||
0.6.6
patch
| ||
0.6.5
patch
| ||
0.6.4
patch
| ||
0.6.3
patch
| ||
0.6.2
patch
| ||
0.6.1
patch
| ||
0.6.0
minor
| ||
0.5.5
patch
| ||
0.5.4
patch
| ||
0.5.3
patch
| ||
0.5.2
patch
| ||
0.5.1
patch
| ||
0.5.0
minor
| ||
0.4.2
patch
| ||
0.4.0
minor
| ||
0.3.1
patch
1 CVE
GHSA-j3px-q95c-9683
RUSTSEC-2024-0401
Nov 14, 2024
zlib-rs stack overflow during decompression with malicious input
5.3
/ 10
Medium
Network
Low
None
None
Unchanged
None
None
Low
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. ImpactDue 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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew LLVM wants to centralize the cleanup before the return (many other blocks jump to 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 hot inner loop and just spends most of its time there). PatchesVersion 0.4.0 patches the problem and is no longer vulnerable. WorkaroundsUsers of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening. Fixed in
0.4.0
References Updated Dec 04, 2024 · Source: OSV.dev | ||
0.3.0
initial
1 CVE
GHSA-j3px-q95c-9683
RUSTSEC-2024-0401
Nov 14, 2024
zlib-rs stack overflow during decompression with malicious input
5.3
/ 10
Medium
Network
Low
None
None
Unchanged
None
None
Low
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. ImpactDue 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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew LLVM wants to centralize the cleanup before the return (many other blocks jump to 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 hot inner loop and just spends most of its time there). PatchesVersion 0.4.0 patches the problem and is no longer vulnerable. WorkaroundsUsers of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening. Fixed in
0.4.0
References Updated Dec 04, 2024 · Source: OSV.dev |