CVE-2026-98267 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
9p: Fix v9fs_issue_write() to update i_size and remote_i_size
Fix v9fs_issue_write() to update i_size and remote_i_size to the new size of the server file if we made it larger, using the start fpos and the count returned by p9_client_write() to calculate the new minimum file size.
This assumes that if the 9P server makes a short write (say it hits ENOSPC), a reduced count is returned.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability described involves a logic error within the v9fs implementation of the Linux kernel, specifically in the function responsible for handling file write operations over the 9P protocol. The 9P network filesystem allows clients to interact with remote servers as if they were local files, relying on accurate state synchronization between the client and the server. When a write operation is initiated via v9fs_issue_write(), the kernel must correctly update its internal representation of the file size, known as i_size, as well as the cached size from the remote server, referred to as remote_i_size. The flaw arises because the original implementation failed to properly calculate and set these size attributes after a write operation completed. This oversight means that the local filesystem metadata does not accurately reflect the actual state of the file on the remote storage system following an append or extension write.
The technical root cause lies in the failure to utilize the starting file position (fpos) combined with the byte count returned by p9_client_write() to determine the new minimum file size. In a correct implementation, if a write operation extends beyond the current end of the file, the kernel must update its internal inode structure to reflect this new extent. By neglecting to perform this calculation and subsequent update, the v9fs layer leaves i_size and remote_i_size stale or incorrect. This discrepancy is particularly problematic when dealing with short writes, such as those resulting from an ENOSPC (No Space Left on Device) error where the server returns a reduced byte count. Even in cases of successful full writes, if the logic for updating size metadata is absent or flawed, the local view diverges from reality.
The operational impact of this vulnerability can manifest in several ways that compromise data integrity and application stability. Applications relying on accurate file sizes may encounter unexpected behavior, such as reading truncated content or failing to recognize newly written data because the inode indicates a smaller file size than what was actually transmitted. In scenarios involving append operations, subsequent writes might overwrite existing data if the offset calculation is based on an incorrect i_size rather than the true end of the file. This can lead to silent data corruption where applications believe they have successfully saved information that is either partially written or inaccessible due to metadata inconsistencies. Furthermore, filesystem tools and utilities that depend on accurate size attributes for reporting or management tasks will provide misleading information, complicating troubleshooting and system administration efforts.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation as it involves the mishandling of return values from network operations to update internal state. It also relates to CWE-682 Incorrect Calculation because the logic for determining file size extension is flawed or missing. In terms of attack vectors and detection, while primarily a reliability issue rather than a direct security exploit like buffer overflows, it falls under ATT&CK technique T1530 Data from Information Repositories if an attacker could manipulate write operations to cause data loss or inconsistency in shared storage environments. The vulnerability is categorized as CWE-20 due to the improper handling of input parameters and return codes that dictate state changes within the kernel subsystem.
Mitigation strategies for this vulnerability involve applying the specific patch provided by the Linux distribution maintainers, which corrects the logic in v9fs_issue_write() to ensure i_size and remote_i_size are updated correctly based on the write offset and returned byte count. System administrators should verify that their kernels include this fix, particularly if they rely heavily on 9P mounts for critical data storage or shared file systems where consistency is paramount. For environments unable to patch immediately, monitoring filesystem logs for anomalies in reported sizes versus actual content length can help detect potential issues caused by the metadata mismatch. Ensuring robust error handling and validation of write operations at the application layer can also provide a secondary defense against inconsistencies arising from kernel-level state desynchronization.