CVE-2024-43806
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedRustix is a set of safe Rust bindings to POSIX-ish APIs. When using `rustix::fs::Dir` using the `linux_raw` backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in `rustix::fs::Dir::read_more`, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the `Dir` iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. `/proc`, `/sys`) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using `rustix::fs::Dir` directly or indirectly (e.g. with the `procfs` crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe rustix library's Dir iterator using the linux_raw backend can get stuck when encountering IO errors, causing an infinite loop in read_more that rapidly allocates unbounded memory (gigabytes in seconds). This leads to OOM crashes. The vulnerability is triggered when iterating over directories that change state (e.g., /proc, /sys) or when accessing a directory file descriptor after the directory is unlinked.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify rustix dependency in your projectSearch your project's Cargo.lock file for 'name = "rustix"' and note the version number listed. Also check Cargo.toml for rustix dependencies.Affected if rustix version is present and is below 0.35.15, 0.36.16, 0.37.25, or 0.38.19 (any version from 0.35.0 through the versions just below these thresholds)
-
Confirm linux_raw backend is in useThe linux_raw backend is the default on Linux systems when using rustix for directory operations. Check if your code uses rustix::fs::Dir or similar directory iteration APIs on Linux. No explicit backend configuration is typically required for linux_raw to be active.Affected if Your application uses rustix Dir iterator on Linux without explicitly opting out of linux_raw backend
-
Identify directory iteration patterns in codeSearch your codebase for patterns that iterate over directories using rustix, particularly targeting /proc, /sys, or directories that may be unlinked during runtime. Look for read_dir, Dir, or similar directory traversal code.Affected if Code iterates over directories that change state (like /proc, /sys) or directories that could be unlinked while a file descriptor remains open
-
Check for runtime memory behaviorMonitor application memory usage during directory iteration operations. If the process exhibits rapid, unbounded memory growth (reaching gigabytes within seconds) while iterating directories, this indicates the vulnerability is being triggered.Affected if Process exhibits rapid unbounded memory allocation during directory iteration, leading toward OOM conditions
You are affected if your project uses rustix with the linux_raw backend at a vulnerable version and performs directory iteration, especially on volatile directories like /proc or /sys.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade rustix to version 0.35.15, 0.36.16, 0.37.25, or 0.38.19 or later. No workarounds exist.
rustix 0.38.19 (or latest 0.38.x stable release)
- Update the rustix dependency in your Cargo.toml file to one of the fixed versions: 0.38.19, 0.37.25, 0.36.16, or 0.35.15
- Run `cargo update` or `cargo build` to fetch the updated dependency
- Verify the build compiles successfully
- Test the application to ensure the directory iteration functionality works correctly
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation1.0 h
- Implementation2.0 h
- Testing4.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,432.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2024-43806 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2024-43806 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data