CVE-2026-98683 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
smb: client: flush dirty data before zeroing a range
smb3_zero_range() emulates FALLOC_FL_ZERO_RANGE by invalidating the page cache over the target range with truncate_pagecache_range() and then issuing FSCTL_SET_ZERO_DATA to the server.
Dirty data was only flushed conditionally, when the range reached or extended EOF. For a purely interior zero range that does not reach EOF, no flush happened, so a dirty folio overlapping the range could be written back to the server after the FSCTL and refill the range that was just zeroed with stale data.
Fix this by unconditionally flushing and waiting for dirty data in the range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA, exactly as was done for smb3_punch_hole() in commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole"); the two paths are structurally identical here.
This is observed as generic/363 randomly reading stale data where a zeroed range is expected against Windows Server.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel SMB client implementation contains a race condition vulnerability within the file allocation control logic, specifically affecting how ranges of files are zeroed out to emulate the FALLOC_FL_ZERO_RANGE operation. This functionality relies on two distinct steps: first, invalidating the local page cache for the target range using truncate_pagecache_range(), and second, issuing an FSCTL_SET_ZERO_DATA command to the remote SMB server to instruct it to mark those blocks as sparse or zeroed. The core technical flaw lies in the conditional nature of data flushing prior to these operations. Historically, dirty data was only flushed when the operation reached or extended beyond the end-of-file (EOF). However, for interior ranges that do not touch EOF, no flush occurred before the page cache was invalidated and the server command issued. This creates a window where stale, unwritten data residing in memory can be written back to the remote storage after the zeroing instruction has already been processed by the server.
This architectural oversight leads to significant data integrity issues because the sequence of events is not atomic from the perspective of the file system state consistency. When an application requests that a specific interior range of a file be zeroed, it expects all subsequent reads within that range to return zeros or uninitialized space depending on the sparse allocation semantics. Due to the missing flush, dirty pages containing older data may still exist in the local cache or pending write-back queues. Once truncate_pagecache_range() removes these pages from the active page cache and FSCTL_SET_ZERO_DATA is sent to the server, the client assumes the range is clean. However, if a background writeback thread subsequently writes those old dirty folios back to the SMB share, they overwrite the zeroed region with stale data. This results in the application reading corrupted or outdated information instead of the expected zeros, violating the contract established by the fallocate system call and breaking assumptions made by applications relying on sparse file semantics for performance optimization or security sanitization.
The operational impact of this vulnerability is primarily observed as intermittent data corruption where files appear to contain old content after being explicitly zeroed out. This behavior was notably detected through generic test case 363 in the fstests suite, which randomly triggers scenarios involving interior range zeroing against Windows Server implementations. The inconsistency arises because the race condition depends on timing; if the dirty pages are flushed naturally before the fallocate call completes, or if they have not yet been dirtied by other processes, the vulnerability remains latent. However, under concurrent load with frequent writes and subsequent zeroing operations, the likelihood of stale data overwriting the intended zeros increases significantly. This can lead to application-level errors, particularly in databases or file formats that rely on precise byte-level control for structure integrity, potentially causing crashes or logical corruption within those applications.
From a vulnerability classification perspective, this issue aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as the race condition stems from improper ordering of cache invalidation and data persistence operations without adequate synchronization barriers. It also relates to CWE-829: Inclusion of Functionality from Untrusted Control Sphere if one considers that the client is trusting the server's state while ignoring its own local dirty buffer state, though the primary failure is internal synchronization within the kernel driver logic. The fix implemented resolves this by unconditionally flushing and waiting for all dirty data in the specified range before proceeding with cache invalidation and sending the FSCTL_SET_ZERO_DATA command. This approach mirrors the mitigation already present in smb3_punch_hole(), ensuring structural consistency across similar file manipulation operations. By enforcing a synchronous write-back of pending changes, the kernel guarantees that no stale local modifications can overwrite the server-side zeroing operation, thereby restoring data integrity and preventing the race condition entirely.