CVE-2026-98683: smb: client: flush dirty data before zeroing a range
In the Linux kernel, the following vulnerability has been resolved:
smb: client: flush dirty data before zeroing a range
smb3zerorange() emulates FALLOCFLZERORANGE by invalidating the page cache over the target range with truncatepagecacherange() and then issuing FSCTLSETZERODATA 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 FSCTLSETZERODATA, exactly as was done for smb3punchhole() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA for a zero range, unconditionally flush and wait for dirty data in the target range to be written back to the server.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel SMB client are exposed when they perform an interior zero-range operation on an SMB3 file. The reported behavior was observed against Windows Server.
What conditions are needed to trigger the stale-data result?
A zeroed range must not reach or extend EOF, and dirty page-cache data must overlap that range. Without a flush before cache invalidation and the server zero-data request, later writeback can restore stale data into the range.
What is the practical impact?
A range expected to contain zeroes can instead return stale data. This can cause incorrect file contents after zero-range operations.
How can I determine whether a system is affected?
The issue is indicated by zero-range operations on SMB3 files intermittently reading stale data, such as the generic/363 test reading stale data where zeroes are expected. The provided data does not identify affected kernel version ranges.