CVE-2024-57952: Revert "libfs: fix infinite directory reads for offset dir"
In the Linux kernel, the following vulnerability has been resolved:
Revert "libfs: fix infinite directory reads for offset dir"
The current directory offset allocator (based on mtree_alloc_cyclic)
stores the next offset value to return in octx->next_offset. This
mechanism typically returns values that increase monotonically over
time. Eventually, though, the newly allocated offset value wraps
back to a low number (say, 2) which is smaller than other already-
allocated offset values.
Yu Kuai <yukuai3@huawei.com> reports that, after commit 64a7ce76fb90
("libfs: fix infinite directory reads for offset dir"), if a
directory's offset allocator wraps, existing entries are no longer
visible via readdir/getdents because offset_readdir() stops listing
entries once an entry's offset is larger than octx->next_offset.
These entries vanish persistently -- they can be looked up, but will
never again appear in readdir(3) output.
The reason for this is that the commit treats directory offsets as
monotonically increasing integer values rather than opaque cookies,
and introduces this comparison:
if (dentry2offset(dentry) >= last_index) {
On 64-bit platforms, the directory offset value upper bound is
2^63 - 1. Directory offsets will monotonically increase for millions
of years without wrapping.
On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator
can wrap after only a few weeks (at worst).
Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for
offset dir") to prepare for a fix that can work properly on 32-bit
systems and might apply to recent LTS kernels where shmem employs
the simple_offset mechanism.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can make directory entries disappear from normal directory listings after an internal offset counter wraps. The files may still exist and be reachable by direct lookup, but software relying on readdir-style enumeration can miss them. The practical risk is availability or operational disruption, mainly on 32-bit systems where wraparound can occur far sooner.
Executive priority
Treat this as a moderate operational reliability issue, not an emergency remote-compromise event. Patch through normal kernel maintenance, with faster handling for 32-bit or embedded Linux environments where the wraparound condition is more plausible.
Technical view
A prior libfs change treated directory offsets as monotonic integers instead of opaque cookies. When the simple offset allocator wraps, offset_readdir() can stop before returning existing entries whose offsets exceed the allocator’s next value. The kernel resolution reverts commit 64a7ce76fb90 pending a fix suitable for 32-bit systems and LTS shmem users.
Likely exposure
Exposure is most relevant to Linux systems using affected 6.11 through 6.14-era kernels, especially 32-bit platforms. The source notes 64-bit offset wrap is effectively impractical, while 32-bit wrap can happen after weeks at worst.
Exploitation context
The CVSS vector is local, low-complexity, and requires low privileges. The provided sources do not state active exploitation, and the CVE is not marked KEV. Impact is availability: persistent omission from directory listings rather than disclosed code execution or data theft.
Researcher notes
Evidence supports a kernel logic regression in libfs directory offset handling. The bundle does not provide weaponized exploit evidence, affected distribution package lists, or complete fixed-version mapping. Focus validation on kernel lineage, architecture, simple_offset usage, and directory enumeration behavior after churn.
Mitigation direction
Update affected Linux kernels through vendor-supported packages or stable kernels containing the referenced fixes.
Prioritize 32-bit Linux systems and workloads using shmem or simple_offset-backed directories.
Check vendor advisories before applying backports, because the source bundle does not name every fixed package version.
Avoid relying solely on directory enumeration for critical recovery workflows until patched.
Validation and detection
Inventory Linux kernel versions and architectures across servers, appliances, containers hosts, and embedded systems.
Check kernel changelogs for CVE-2024-57952 or referenced stable commit IDs.
Identify workloads where missing directory entries would affect availability, cleanup, backup, or monitoring.
Run regression tests that confirm existing entries remain visible through normal directory listing APIs.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-57952 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.