ZeroHour

CVE-2026-89713

large

Linux kernel NFSD TOCTOU lets NFS clients truncate append-only files

CVSS 3.1
9.1 critical
EPSS
Published
()
Modified
AI analysis

A time-of-check-to-time-of-use (TOCTOU) race in the Linux kernel's NFS server (nfsd_setattr) allows the append-only truncation protection to be bypassed. The permission check samples the file size without holding inode_lock(), so an NFS client that sends a SETATTR which does not shrink the file at that moment, while a concurrent append extends the file, causes notify_change() to later apply a real truncation without the NFSD_MAY_TRUNC check that would have rejected the operation on an IS_APPEND inode. A successful attack lets an unauthenticated remote NFS client truncate files marked append-only — typically audit logs and other tamper-evident data — causing loss of integrity and availability of that data, reflected in the CVSS 3.1 score of 9.1. Affected systems are Linux machines exporting filesystems via kernel NFSD where clients can reach an exported append-only file. No public proof-of-concept exists and the flaw is not known to be exploited in the wild.

What to do: Patch: install a kernel release containing the NFSD fix as soon as your distribution ships it and reboot/restart nfsd. In the meantime, restrict NFS exports to trusted hosts and networks (firewall TCP/2049, tight export lists, root_squash), since exploitation requires client access to an exported append-only file. Audit append-only files such as logs for unexpected size decreases or truncation events, and treat any observed shrinkage of an append-only file as a potential indicator of compromise.

Affected
Linux kernel (NFSD)
Estimated exposure
large≈ tens of thousands of internet-exposed NFS servers (TCP/2049), plus a larger unseen population on internal networks — Internet-wide scan services (e.g., Shodan/Censys) consistently report on the order of tens of thousands of exposed NFS endpoints, while NFS is predominantly deployed on internal enterprise networks, so total affected deployments plausibly…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: NFSD: check truncate permission under inode lock nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change(). 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 nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), 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 get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load.

Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

In the news

No ingested article mentions this CVE yet.