Cloudanix VulnDB

CVE-2026-98684

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recent Linux kernel fix prevents a timing problem that could cause file data to be silently erased when working with Windows file servers over the network.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in SMB3 client fallocate emulation where FSCTL_QUERY_ALLOCATED_RANGES is issued without flushing pending writes, allowing the server to report written ranges as unallocated holes and causing subsequent zero-fill to overwrite live data.

Why it matters to the business

Risk of silent data corruption on files stored on Windows servers when Linux clients perform certain fallocate or fsx operations, potentially leading to application failures or loss of integrity in shared storage workflows.

How an attack unfolds

An attacker or workload writes data to a file over SMB3, immediately triggers the mode-0 fallocate emulation path which calls FSCTL_QUERY_ALLOCATED_RANGES without an intervening flush, receives a stale empty range list from the Windows server, and overwrites the newly written data with zeros.

How to fix it

Update the Linux kernel to a version containing the fix that issues writeback, drains I/O, and sends SMB2 FLUSH before FSCTL_QUERY_ALLOCATED_RANGES; apply distribution-specific kernel packages released after 2026-10-18.

How to confirm the fix worked

Confirm kernel changelog or commit message references the flush-before-query change; re-run fsx/generic-363 test suite against Windows Server 2022 for 100000 iterations and verify no corruption occurs.

Typical attack path

  1. Establish SMB3 session to Windows server
  2. Write data to interior file range
  3. Invoke fallocate with FALLOC_FL_KEEP_SIZE on overlapping range
  4. SMB3 client issues FSCTL_QUERY_ALLOCATED_RANGES without flush
  5. Server returns empty allocated list due to lack of coherency
  6. Client zero-fills reported hole, destroying live data

How to detect it

Review SMB client logs and kernel traces for repeated FSCTL_QUERY_ALLOCATED_RANGES immediately following writes without intervening FLUSH; inspect application logs for unexpected zero-filled regions after fallocate calls.

What your security team should do

  • Prioritize kernel updates on all systems mounting SMB3 shares to Windows servers
  • Monitor EPSS and KEV status for any rise in exploit maturity
  • Temporarily restrict fallocate usage or switch to Samba servers until patched

The record

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.

Affected packages

Ecosystem Package Introduced Fixed