CVE-2025-21900: NFSv4: Fix a deadlock when recovering state on a sillyrenamed file
In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Fix a deadlock when recovering state on a sillyrenamed file
If the file is sillyrenamed, and slated for delete on close, it is
possible for a server reboot to triggeer an open reclaim, with can again
race with the application call to close(). When that happens, the call
to put_nfs_open_context() can trigger a synchronous delegreturn call
which deadlocks because it is not marked as privileged.
Instead, ensure that the call to nfs4_inode_return_delegation_on_close()
catches the delegreturn, and schedules it asynchronously.
Security readout for executives and security teams
Plain-English summary
A Linux NFSv4 locking flaw can freeze affected file operations when an NFS server reboots while an application closes a deleted-but-still-open file. The documented impact is loss of availability, not data theft or modification.
Executive priority
Prioritize normal high-severity patching for NFS-dependent production systems, especially where a deadlock could interrupt critical services. Accelerate remediation for environments with frequent NFS server failovers or reboots. This is not supported as an emergency internet-wide exploitation event by the supplied evidence.
Technical view
During NFSv4 state recovery, an open reclaim can race with close processing for a sillyrenamed, delete-on-close file. A synchronous delegation return may then deadlock because it lacks privileged handling. The fix catches that return and schedules it asynchronously. The record assigns CVSS 7.5 and CWE-667.
Likely exposure
Exposure is limited to Linux systems using affected NFSv4 code and encountering the specific server-reboot, state-reclaim, and concurrent-close conditions. The supplied version data names 6.11, 6.12.18, 6.13.6, and 6.14 but is ambiguous; confirm exact affected ranges with the kernel or distribution vendor.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation. Although the CVSS vector is network-based, the documented trigger depends on a particular NFSv4 recovery race. Treat it primarily as an availability risk until stronger exploitation evidence appears.
Researcher notes
The affected-version representation is internally unclear, including an unexplained "0" entry and repeated commit identifiers marked unaffected. Avoid deriving precise vulnerable ranges from this bundle alone. Validate ancestry or vendor backports against the three stable-kernel commits. The described security consequence is availability loss through improper locking.
Mitigation direction
Apply a vendor-supported kernel update confirmed to contain the linked upstream fix.
Prioritize NFSv4 clients supporting business-critical or high-availability workloads.
If immediate updating is impossible, consult the Linux distribution vendor for supported mitigations.
Schedule maintenance carefully because kernel remediation normally requires activating the updated kernel.
Validation and detection
Inventory Linux kernel versions on systems mounting or serving NFSv4 workloads.
Compare installed kernels with current distribution advisories and the CVE record.
Confirm the installed kernel includes the applicable linked stable fix.
After updating, verify the running kernel version, not only installed packages.
Test server-reboot and NFS recovery behavior in a non-production environment.
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.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-667 · source CWE mapping
Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.