# GHSA-j3px-q95c-9683: Denial of service because of stack overflow with malicious decompression input

> A maliciously crafted input can cause a stack overflow in zlib-rs, crashing the application and resulting in a denial of service.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 14 Nov 2024
- **Also known as:** RUSTSEC-2024-0401

## What is GHSA-j3px-q95c-9683?

GHSA-j3px-q95c-9683 is a denial of service vulnerability in libz-rs-sys, published on 14 Nov 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

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

## Which versions are affected by GHSA-j3px-q95c-9683?

7 open source packages ship an affected version, including libz-rs-sys, libz-rs-sys-cdylib and zlib-rs.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `libz-rs-sys` | crates.io | All versions | 0.4.0 |
| `libz-rs-sys` | crates.io | All versions | 0.4.0 |
| `libz-rs-sys-cdylib` | crates.io | All versions | 0.4.0 |
| `libz-rs-sys-cdylib` | crates.io | All versions | 0.4.0 |
| `zlib-rs` | crates.io | All versions | 0.4.0 |
| `zlib-rs` | crates.io | All versions | 0.4.0 |
| `zlib-rs` | crates.io | From 0.0.0-0 | 0.4.0 |

## How do I fix GHSA-j3px-q95c-9683?

Upgrade libz-rs-sys to 0.4.0 or later.

## Is GHSA-j3px-q95c-9683 being exploited?

There is no known exploitation of GHSA-j3px-q95c-9683 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-j3px-q95c-9683 and fix it if it is affected.

What it is: GHSA-j3px-q95c-9683 is a denial of service vulnerability in libz-rs-sys, published on 14 Nov 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-j3px-q95c-9683 in the wild and no public exploit code.

Affected packages and fixed versions:
- libz-rs-sys (crates.io): affected all versions; fixed in 0.4.0
- libz-rs-sys (crates.io): affected all versions; fixed in 0.4.0
- libz-rs-sys-cdylib (crates.io): affected all versions; fixed in 0.4.0
- libz-rs-sys-cdylib (crates.io): affected all versions; fixed in 0.4.0
- zlib-rs (crates.io): affected all versions; fixed in 0.4.0
- zlib-rs (crates.io): affected all versions; fixed in 0.4.0
- zlib-rs (crates.io): affected from 0.0.0-0; fixed in 0.4.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-j3px-q95c-9683/ (Markdown: https://insights.sbomify.com/GHSA-j3px-q95c-9683/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-j3px-q95c-9683

---
From sbomify Insights: https://insights.sbomify.com/GHSA-j3px-q95c-9683/
Summaries are generated and may contain mistakes; the official description above is the record.