CVE-2026-89713: NFSD: check truncate permission under inode lock
In the Linux kernel, the following vulnerability has been resolved:
NFSD: check truncate permission under inode lock
nfsdsetattr() checks whether a size update needs NFSDMAYTRUNC before it takes inodelock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTRSIZE update is applied later under inodelock() by notifychange().
This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsdsetattr() takes inodelock(). notifychange() then applies a real truncation without the NFSDMAYTRUNC check that rejects ISAPPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notifychange(), so NFSD must make this decision against the locked size it is about to change.
Split the write-count acquisition from the truncation permission check. Keep getwriteaccess() before the locked setattr work, then recheck whether the requested size is below isizeread(inode) after inodelock() has been acquired and before notifychange(ATTRSIZE). This also avoids the plain unlocked inode->isize load.
Affected Software
Event History
Frequently Asked Questions
Which systems and files are exposed to this issue?
Systems running the Linux kernel NFSD server are exposed when they serve append-only files. The affected path is an NFS client SETATTR request that changes file size.
What does an attacker or client need to trigger the flaw?
The client must issue a size update that is not a shrink when NFSD first reads the file size. A concurrent append must then extend the file before NFSD acquires the inode lock and applies the requested size.
What is the security impact of the race?
The race can cause NFSD to apply a real truncation to an append-only file without performing the NFSD_MAY_TRUNC permission check that would reject truncation of such files.