CVE-2026-23053: NFS: Fix a deadlock involving nfs_release_folio()
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a deadlock involving nfsreleasefolio()
Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery waiting on kthreadd, which is attempting to reclaim memory by calling nfsreleasefolio(). The latter cannot make progress due to state recovery being needed.
It seems that the only safe thing to do here is to kick off a writeback of the folio, without waiting for completion, or else kicking off an asynchronous commit.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Compensating control
In nfs_release_folio(), initiate writeback of the folio without waiting for completion, or initiate an asynchronous commit, to avoid the NFSv4.1 state-recovery deadlock.
Event History
Frequently Asked Questions
Which systems are exposed to this deadlock?
Systems using the Linux kernel with NFSv4.1 are implicated, particularly where NFSv4.1 state recovery can coincide with memory reclaim activity.
What conditions trigger the issue?
The deadlock occurs when NFSv4.1 state recovery waits on kthreadd while kthreadd is reclaiming memory and calls nfs_release_folio(). Progress then depends on the same state recovery that is waiting.
What is the effect of successful triggering?
The affected tasks can deadlock, preventing the involved NFS state recovery and memory-reclaim paths from making progress.
What does the available fix change?
The fix avoids waiting for completion in nfs_release_folio() under these conditions. It instead starts folio writeback without waiting, or starts an asynchronous commit.