https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 17 Oct 2026 10:44:17 +0000 https://cve.radiocsirt.org/vuln/ghsa-j3px-q95c-9683 <p><strong>Affected:</strong> crates.io: zlib-rs, crates.io: libz-rs-sys, crates.io: libz-rs-sys-cdylib</p> <p>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.</p> <p>### Impact</p> <p>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.</p> <p>After stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew</p> <p>```asm .LBB109_326: mov rdi, rbx call zlib_rs::inflate::State::type_do jmp .LBB109_311</p> <p>.LBB109_311: lea rsp, [rbp - 40] pop rbx pop r12 pop r13 pop r14 pop r15 pop rbp .cfi_def_cfa rsp, 8 ret ```</p> <p>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&#39;t currently have the power to tell LLVM what we want it to do.</p> <p>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&#39;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…</p> <p><strong>Affected:</strong> crates.io: zlib-rs, crates.io: libz-rs-sys, crates.io: libz-rs-sys-cdylib</p> <p>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.</p> <p>### Impact</p> <p>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.</p> <p>After stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew</p> <p>```asm .LBB109_326: mov rdi, rbx call zlib_rs::inflate::State::type_do jmp .LBB109_311</p> <p>.LBB109_311: lea rsp, [rbp - 40] pop rbx pop r12 pop r13 pop r14 pop r15 pop rbp .cfi_def_cfa rsp, 8 ret ```</p> <p>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&#39;t currently have the power to tell LLVM what we want it to do.</p> <p>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&#39;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…</p> https://cve.radiocsirt.org/vuln/ghsa-j3px-q95c-9683