CVE-2026-98684 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
smb: client: flush and commit data before querying allocated ranges
The mode 0 / FALLOC_FL_KEEP_SIZE fallocate emulation for small interior ranges in smb3_simple_fallocate_range() issues FSCTL_QUERY_ALLOCATED_RANGES and zero-fills any sub-range the server reports as an unallocated hole, to force block allocation without changing file contents.
This is unsafe against Windows servers. Per the Win32 documentation, FSCTL_QUERY_ALLOCATED_RANGES only reports ranges that *may* contain nonzero data and is explicitly not coherent with recently written data:
"a call to FSCTL_QUERY_ALLOCATED_RANGES [after writing to a network
file] would not necessarily return a correct list of allocated regions. To ensure coherency [...] flush the data to the file"
fsx (generic/363) reproduces the resulting corruption against Windows Server 2022: a range is written, an uncached read returns the data, yet the next FSCTL_QUERY_ALLOCATED_RANGES on that range reports it as a whole hole, so the emulation overwrites live data with zeroes. A network trace confirmed the WRITE, the READ returning data and the query returning an empty range list within microseconds. Samba does not exhibit this; its query is coherent with the written data.
Write back the dirty pages, drain any outstanding I/O and issue an SMB2 FLUSH to force the server to commit the data before querying the allocated ranges, so the query reflects the data actually present.
With this, generic/363 passes against both Windows Server 2022 and Samba over 100000 fsx operations.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability resides in the SMB3 client implementation within the Linux kernel, specifically affecting the fallocate emulation logic used for mode zero or FALLOC_FL_KEEP_SIZE operations on small interior file ranges. The core technical flaw is a race condition caused by insufficient synchronization between data writes and metadata queries when interacting with certain network file servers, particularly Microsoft Windows Server implementations. When an application requests to allocate space within a file without changing its size, the Linux SMB client attempts to emulate this behavior by first querying the server for allocated ranges using the FSCTL_QUERY_ALLOCATED_RANGES control code. The logic assumes that any range reported as unallocated is effectively a hole and proceeds to zero-fill it to force block allocation on the server side. However, this approach fails to account for the asynchronous nature of network I/O and the specific coherency semantics defined by Windows servers.
The root cause lies in the violation of file system consistency protocols mandated by Microsoft's Win32 documentation regarding FSCTL_QUERY_ALLOCATED_RANGES. This control code is designed to report ranges that may contain nonzero data, but it explicitly does not guarantee coherence with recently written data unless specific flushing operations have been performed. In a typical scenario involving Windows Server 2022, an application writes data to a file range and immediately follows up with the fallocate operation. The Linux client issues a write request and then promptly sends FSCTL_QUERY_ALLOCATED_RANGES without ensuring that the previous write has been committed or acknowledged by the server. Due to network latency and internal buffering on the Windows side, the query returns an empty list for the recently written range, incorrectly identifying it as unallocated space. Consequently, the Linux client proceeds to zero-fill this region based on the flawed assumption that no data exists there.
The operational impact of this vulnerability is severe data corruption within files accessed over SMB3 mounts. Because the client blindly trusts the server's report of allocated ranges without verifying write completion, live data written by applications can be overwritten with zeros. This results in silent data loss where file contents are destroyed after being successfully stored on the remote storage system. The issue has been reproduced using generic fsx test case 363 against Windows Server 2022, demonstrating that uncached reads return valid data while subsequent allocation queries incorrectly report those same ranges as holes. In contrast, Samba implementations do not exhibit this behavior because their query mechanism maintains coherence with written data, highlighting that the flaw is specific to how Linux interacts with Microsoft's server-side caching and coherency models rather than a universal SMB protocol defect.
To mitigate this vulnerability, the kernel logic was updated to enforce strict ordering of operations before querying allocated ranges. The fix requires writing back dirty pages from the local cache to ensure data integrity at the client level, draining any outstanding I/O requests to guarantee they have been processed by the network stack, and explicitly issuing an SMB2 FLUSH command to force the server to commit all pending writes to persistent storage. Only after these steps are completed does the client proceed with FSCTL_QUERY_ALLOCATED_RANGES queries. This ensures that the list of allocated ranges returned by the server accurately reflects the current state of data on disk, preventing the erroneous zeroing of live file regions. With this correction, standard validation tests such as generic/363 pass successfully against both Windows Server 2022 and Samba environments over extensive operation counts, confirming that coherency is maintained across different SMB server implementations.
From a security taxonomy perspective, this vulnerability aligns with CWE-367, which describes Time-of-check to time-of-use (TOCTOU) race conditions in file systems. The client checks the allocated status of a range and then uses that information to modify data, but the state changes between these two steps due to asynchronous network operations. Additionally, it relates to CWE-20, Improper Input Validation, as the client fails to validate that the server's response is consistent with recent local write operations before acting upon it. In terms of MITRE ATT&CK mapping, this behavior could be leveraged in scenarios where an attacker controls or influences data on a network share to cause denial of service through data corruption, although the primary vector here is accidental rather than malicious exploitation. The fix emphasizes the importance of adhering to strict I/O ordering and coherency guarantees when interacting with distributed file systems that have distinct caching models compared to local storage.