zlib-rs

Version	Released
`0.6.8` patch	Sep 15, 2026
`0.6.7` patch	Aug 03, 2026
`0.6.6` patch	Jul 09, 2026
`0.6.5` patch	Jul 01, 2026
`0.6.4` patch	Jun 21, 2026
`0.6.3` patch	Mar 02, 2026
`0.6.2` patch	Feb 17, 2026
`0.6.1` patch	Feb 17, 2026
`0.6.0` minor	Jan 23, 2026
`0.5.5` patch	Dec 22, 2025
`0.5.4` patch	Dec 10, 2025
`0.5.3` patch	Dec 03, 2025
`0.5.2` patch	Sep 02, 2025
`0.5.1` patch	Jun 06, 2025
`0.5.0` minor	Apr 01, 2025
`0.4.2` patch	Feb 20, 2025
`0.4.1` patch	Dec 16, 2024
`0.4.0` minor	Nov 14, 2024
`0.3.1` patch 1 CVE	Oct 04, 2024
`0.3.0` minor 1 CVE	Sep 05, 2024
`0.2.1` patch 1 CVE	Jul 08, 2024
`0.2.0` minor 1 CVE	Jun 12, 2024
`0.1.1` patch 1 CVE	Apr 22, 2024
`0.1.0` minor 1 CVE	Apr 16, 2024
`0.0.1` initial 1 CVE	Feb 23, 2024

0.6.8 patch

Sep 15, 2026

0.6.7 patch

Aug 03, 2026

0.6.6 patch

Jul 09, 2026

0.6.5 patch

Jul 01, 2026

0.6.4 patch

Jun 21, 2026

0.6.3 patch

Mar 02, 2026

0.6.2 patch

Feb 17, 2026

0.6.1 patch

Feb 17, 2026

0.6.0 minor

Jan 23, 2026

0.5.5 patch

Dec 22, 2025

0.5.4 patch

Dec 10, 2025

0.5.3 patch

Dec 03, 2025

0.5.2 patch

Sep 02, 2025

0.5.1 patch

Jun 06, 2025

0.5.0 minor

Apr 01, 2025

0.4.2 patch

Feb 20, 2025

0.4.1 patch

Dec 16, 2024

0.4.0 minor

Nov 14, 2024

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.

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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew

.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 hot inner loop and just spends most of its time there).

Patches

Version 0.4.0 patches the problem and is no longer vulnerable.

Workarounds

Users 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

Oct 04, 2024

0.3.0 minor

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.

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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew

.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 hot inner loop and just spends most of its time there).

Patches

Version 0.4.0 patches the problem and is no longer vulnerable.

Workarounds

Users 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

Sep 05, 2024

0.2.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.

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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew

.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 hot inner loop and just spends most of its time there).

Patches

Version 0.4.0 patches the problem and is no longer vulnerable.

Workarounds

Users 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

Jul 08, 2024

0.2.0 minor

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.

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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew

.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 hot inner loop and just spends most of its time there).

Patches

Version 0.4.0 patches the problem and is no longer vulnerable.

Workarounds

Users 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

Jun 12, 2024

0.1.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.

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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew

.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 hot inner loop and just spends most of its time there).

Patches

Version 0.4.0 patches the problem and is no longer vulnerable.

Workarounds

Users 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

Apr 22, 2024

0.1.0 minor

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.

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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew

.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 hot inner loop and just spends most of its time there).

Patches

Version 0.4.0 patches the problem and is no longer vulnerable.

Workarounds

Users 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

Apr 16, 2024

0.0.1 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.

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 with a fuzzer, we dove into the assembly, and found some cases where the stack grew

.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 hot inner loop and just spends most of its time there).

Patches

Version 0.4.0 patches the problem and is no longer vulnerable.

Workarounds

Users 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

Feb 23, 2024

Activity

Reach

Details

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Impact

Patches

Workarounds