CVE-2026-89713 in Linux
Summary
by MITRE • 09/11/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in the Linux kernel involves a time-of-check to time-of-use race condition within the Network File System daemon, specifically affecting how file attribute changes are processed under concurrent access scenarios. The core issue resides in the nfsd_setattr function, which is responsible for handling SETATTR requests from NFS clients that modify file attributes such as size. In the flawed implementation, the system performs a permission check to determine if truncation rights (NFSD_MAY_TRUNC) are required before acquiring the inode lock. This initial assessment relies on an unlocked read of the current file size. However, the actual modification of the attribute is deferred until after the inode lock is acquired and executed via notify_change. This sequence creates a critical window where the state of the filesystem can change between the permission check and the execution of the truncation operation.
This race condition poses a significant security risk for files marked with the append-only flag, which corresponds to the IS_APPEND attribute in Linux VFS semantics. When an NFS client sends a SETATTR request intended to shrink or truncate a file, the daemon checks if the new size is smaller than the current size sampled without locking. If it is, and no concurrent modification occurs during that brief interval, the system proceeds to acquire the lock and apply the change. However, if another process appends data to the file concurrently between the unlocked sample and the locked execution of notify_change, the actual file size may have increased beyond what was originally sampled. Consequently, the subsequent truncation operation might effectively delete or overwrite data that was appended after the initial check but before the lock was acquired. Crucially, because the permission check occurred on stale data, the system fails to recognize that it is attempting to modify an append-only file in a way that violates security policies, thereby bypassing the safeguards designed to prevent unauthorized modifications to protected files.
The operational impact of this vulnerability allows for potential privilege escalation or data integrity violations depending on the context and privileges of the attacker. An adversary with write access to such a file could exploit this race condition to circumvent append-only restrictions, effectively gaining the ability to truncate or overwrite content that should be immutable. This undermines the security model provided by Linux VFS protections, which are designed to ensure that once a file is marked as append-only, no process can delete or modify existing data, only add new data at the end. The vulnerability highlights a broader class of issues where filesystem operations rely on non-atomic checks against mutable state without proper synchronization, leading to inconsistencies between policy enforcement and actual system behavior.
To mitigate this risk, the Linux kernel developers have implemented a fix that restructures the order of operations within nfsd_setattr. The solution involves splitting the acquisition of write access from the truncation permission check. Specifically, get_write_access is now called before entering the locked setattr work section to ensure proper accounting and locking semantics are established early. More importantly, after acquiring inode_lock(), the system performs a fresh recheck of whether the requested size is below the current i_size_read(inode) value obtained under lock protection. This ensures that any concurrent modifications made by other processes during the initial unlocked phase are accounted for before notify_change is invoked with ATTR_SIZE. By validating the truncation permission against the locked, up-to-date file size, the system guarantees that append-only checks reflect the true state of the inode at the moment of modification, thereby closing the race window and restoring correct security enforcement.
From a classification perspective, this vulnerability aligns with CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition, as it involves checking a condition for validity before using that information in an action without ensuring the state has not changed. In terms of attack vectors and techniques, this scenario relates to ATT&CK technique T1085: Truncation, where an attacker modifies file contents by removing data from the end or beginning of a file. The exploitation relies on precise timing and concurrent access patterns typical in multi-threaded or network-driven environments, emphasizing the importance of atomic operations and proper locking strategies when handling shared resources like filesystem inodes.