CVE-2024-43806

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