CVE-2025-71072: shmem: fix recovery on rename failures
In the Linux kernel, the following vulnerability has been resolved:
shmem: fix recovery on rename failures
maple_tree insertions can fail if we are seriously short on memory;
simple_offset_rename() does not recover well if it runs into that.
The same goes for simple_offset_rename_exchange().
Moreover, shmem_whiteout() expects that if it succeeds, the caller will
progress to d_move(), i.e. that shmem_rename2() won't fail past the
successful call of shmem_whiteout().
Not hard to fix, fortunately - mtree_store() can't fail if the index we
are trying to store into is already present in the tree as a singleton.
For simple_offset_rename_exchange() that's enough - we just need to be
careful about the order of operations.
For simple_offset_rename() solution is to preinsert the target into the
tree for new_dir; the rest can be done without any potentially failing
operations.
That preinsertion has to be done in shmem_rename2() rather than in
simple_offset_rename() itself - otherwise we'd need to deal with the
possibility of failure after successful shmem_whiteout().
Security readout for executives and security teams
Plain-English summary
A Linux shared-memory filesystem rename can fail under severe memory pressure and leave filesystem state improperly recovered. The supplied assessment rates potential impact as high, primarily because availability could be seriously affected and limited integrity damage is possible. Business risk depends on whether affected kernels and shmem/tmpfs rename paths are present.
Executive priority
Prioritize assessment and planned patching as a high-severity availability issue, especially for memory-constrained or tmpfs-intensive services. Emergency internet-wide response is not supported by the supplied evidence because active exploitation and a practical remote attack path are unconfirmed.
Technical view
Maple-tree insertions used by shmem rename and rename-exchange operations can fail during extreme memory scarcity. Existing recovery ordering can then mishandle directory offsets or violate assumptions following successful whiteout creation. The kernel fixes preinsert the target and reorder operations so remaining tree stores cannot fail.
Likely exposure
Potentially exposed assets are Linux systems running affected kernel releases and exercising shmem/tmpfs rename operations, particularly under severe memory pressure. The supplied version data identifies 6.6, 6.12.64, 6.18.3, and 6.19, but does not provide clear affected ranges or distribution package mappings.
Exploitation context
The supplied record does not report known exploitation, and the CVE is not listed as KEV. Although its CVSS vector says network-accessible without privileges or interaction, the technical description alone does not establish how an external attacker could reach the vulnerable rename path. Treat remote exploitability as unconfirmed.
Researcher notes
The invariant is that successful shmem_whiteout must be followed by d_move without a later failure. Fixes avoid fallible maple-tree insertion after irreversible progress by preinserting the destination or reordering exchange operations. Public evidence supplied here does not identify a reproducer, root-cause CWE, affected-range boundaries, or demonstrated security exploitation.
Mitigation direction
Apply a vendor-supported kernel release containing the referenced upstream stable fix.
Consult Linux distribution advisories for exact affected and corrected package versions.
Prioritize memory-constrained hosts that rely heavily on tmpfs or shared-memory filesystems.
Use normal maintenance controls and reboot when required to activate the corrected kernel.
Validation and detection
Inventory running kernel versions and Linux distribution package revisions.
Identify systems mounting or heavily using tmpfs and other shmem-backed filesystems.
Confirm the installed kernel includes an applicable referenced stable commit or vendor backport.
After updating, verify the running kernel changed and required filesystems operate normally.
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-2025-71072 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.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
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.