CVE-2024-43806

What it actually does

The flaw is an availability issue in the rustix safe Rust bindings when `rustix::fs::Dir` is used with the `linux_raw` backend. If directory iteration encounters an I/O error and the caller continues iterating instead of stopping, the iterator can become stuck. A related memory over-allocation behavior in `rustix::fs::Dir::read_more` can then rapidly allocate unbounded memory, potentially consuming gigabytes within seconds on hot code paths. This can terminate the affected process through the operating system OOM killer. The issue is most relevant to applications that enumerate unstable directories, such as Linux virtual filesystems under `/proc` or `/sys`, or applications that indirectly use vulnerable rustix behavior through crates such as `procfs`. The impact is denial of service; confidentiality and integrity are not directly affected.

Why it matters to the business

Successful exploitation can crash an application or service by forcing it to exhaust host memory. For production systems, this can cause service outages, failed background jobs, degraded monitoring or inventory functions, container restarts, and potential collateral impact to co-located workloads if memory controls are weak. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad opportunistic exploitation is less likely; however, systems that expose APIs or workflows that trigger directory enumeration on attacker-influenced paths should still be prioritized because exploitation can be fast and disruptive once the vulnerable code path is reachable.

How an attack unfolds

An attacker first identifies an application built with an affected rustix version, or with a dependency that uses rustix directory iteration through the `linux_raw` backend. The attacker then looks for an exposed function, API, command, or workflow that causes the application to enumerate directories, especially volatile Linux virtual filesystem locations such as `/proc` or `/sys`, or a directory whose file descriptor can become invalid after unlinking or similar state changes. If the application continues after directory iteration errors, the attacker repeatedly triggers that workflow or races filesystem state changes so the iterator enters the stuck error state. Once stuck, repeated calls can cause `Dir::read_more` to allocate memory rapidly until the process or host exceeds memory limits. The usual result is an OOM kill, process crash, or container restart, producing a denial-of-service condition. Exploitation is implementation-specific: an attacker needs a reachable application path that performs vulnerable directory iteration and does not stop on errors.

How to fix it

Upgrade rustix to a fixed release for the branch in use: 0.35.15, 0.36.16, 0.37.25, or 0.38.19 or later. For source builds pinned to Git, ensure the fix commit `954bb0d17641c0c6460ea4c06968eff37e73083a` or a later commit is present. Rebuild and redeploy all binaries that statically include the affected Rust dependency, because Rust applications commonly vendor or compile dependencies into the final executable. For Android platform usage, consume vendor/platform updates that include the fixed `platform/packages/modules/Bluetooth` version noted for Android 13 and 13-next `2023-04-01` or later. There are no complete workarounds for the underlying library issue, but risk can be reduced by ensuring directory iterators stop on I/O errors, avoiding unbounded enumeration of volatile virtual filesystems, applying request rate limits around filesystem-inspection endpoints, and enforcing container or service memory limits so one process cannot exhaust the host.

How to confirm the fix worked

Confirm dependency remediation by inspecting `Cargo.lock`, SBOMs, build manifests, and compiled artifact provenance for `rustix` versions. Any affected branch should show at least `0.35.15`, `0.36.16`, `0.37.25`, or `0.38.19`; Git-pinned builds should include commit `954bb0d17641c0c6460ea4c06968eff37e73083a` or later. Use `cargo tree -i rustix` to identify which top-level crates pull in rustix, and repeat this check for each built binary or container image. Confirm that CI/CD rebuilds occurred after the dependency update rather than only updating source manifests. For running services, validate deployed image digests or package versions against the rebuilt artifacts. Functional validation should include tests where directory enumeration encounters I/O errors, deleted directories, and volatile `/proc` or `/sys` entries, confirming the application exits the iterator cleanly and memory usage remains bounded.

Typical attack path

1. Identify a service or application that includes a vulnerable rustix dependency or a dependent crate such as one that inspects `/proc`.
2. Find an externally or locally reachable feature that causes the application to enumerate directories.
3. Supply input, trigger a workflow, or manipulate filesystem state so the enumerated directory becomes unstable, unlinked, or produces I/O errors during iteration.
4. Cause the vulnerable code to continue iterating after the error rather than aborting the directory scan.
5. Repeat or sustain the triggering action until the process rapidly allocates excessive memory.
6. Wait for the operating system, container runtime, or service manager to terminate or restart the process due to out-of-memory conditions.

How to detect it

Look for evidence of rapid memory exhaustion followed by process termination in applications known to include vulnerable rustix versions or dependent crates. Useful log sources include Linux kernel logs, `journalctl`, systemd service logs, container runtime events, Kubernetes pod events, application logs, crash reports, and APM memory telemetry. Search for OOM-killer messages, container exit code 137, Kubernetes `OOMKilled` states, sudden resident-set-size growth, repeated restarts, and application stack traces mentioning `rustix::fs::Dir`, `read_more`, directory iteration, `/proc`, or `/sys`. Correlate these events with inbound API requests or local user actions that trigger process, network, Bluetooth, or filesystem inventory operations. Because there are no known public exploit indicators and exploitation is application-specific, detection should focus on behavioral artifacts: repeated triggering of enumeration-heavy endpoints, memory growth measured in seconds, and OOM termination shortly after directory traversal errors such as missing entries, stale file handles, or I/O errors.

• rustix::fs::Dir
• rustix::fs::Dir::read_more
• linux_raw
• procfs
• /proc
• /sys
• Out of memory: Killed process
• oom-kill
• oom_reaper
• Killed process
• Memory cgroup out of memory
• Task in / killed as a result of limit
• OOMKilled
• exit code 137
• Reason: OOMKilled
• stale file handle
• No such file or directory
• Input/output error

What your security team should do

• Inventory Rust applications, containers, and embedded components that include `rustix`, especially services that inspect `/proc`, `/sys`, process metadata, network interfaces, or filesystem state.
• Prioritize remediation for exposed services, privileged agents, monitoring tools, Bluetooth/platform components, and any application where untrusted users can trigger filesystem enumeration.
• Upgrade to the fixed rustix branch version or later and rebuild all affected binaries; do not rely only on updating a lockfile without redeployment.
• Search dependency graphs for indirect exposure through crates that use rustix directory iteration, including process-filesystem inspection libraries.
• Add regression tests for directory iteration failures and require code paths to stop or fail closed on iterator errors.
• Set or review container, systemd, and orchestration memory limits to reduce blast radius if a similar memory-exhaustion condition is triggered.
• Monitor for unexplained OOM kills or rapid memory spikes in services that perform filesystem or process enumeration.
• Because this is not in KEV and has low EPSS, handle as a targeted availability risk rather than an internet-wide emergency unless a critical exposed code path is confirmed.