Live › vulnerability › CVE-2026-98683
Go to dashboardIn the Linux kernel's SMB3 client, a zero-range operation over an interior part of a file did not flush dirty page-cache data first, so a dirty page could be written back after the server zeroed the range and restore old contents. The fix flushes and waits for dirty data in the range before invalidating the cache and issuing the zero-data request.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the SMB3 client (cifs/smb3) that mount network shares and use fallocate FALLOC_FL_ZERO_RANGE on files over SMB. The sources observed stale reads against Windows Server in the generic/363 test. Hosts that do not mount SMB shares, or that do not use zero-range fallocate, can skip it.
No product ranges from the sources yet.
uname -r and compare against the kernel version that contains the upstream fix (unknown from the sources)mount -t cifs or mount -t smb3 on the affected hostEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98683")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.