---
id: "CVE-2026-98684"
kind: "vulnerability"
aliases: ["CVE-2026-98684"]
title: "Linux kernel SMB client: fallocate could overwrite live data with zeroes"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["file-servers", "linux-kernel", "package", "smb3-client", "windows-server"]
not_affected_if: ["no-smb-mounts", "samba-server"]
published_at: "2026-10-18T16:17:21+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:19:11+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98684", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel SMB client: fallocate could overwrite live data with zeroes

The Linux kernel's SMB client emulated fallocate on small interior ranges by querying allocated ranges from the server, but Windows servers can report written data as a hole. The client then zero-filled that range, overwriting live file data.

_Summary, check and fix written by a model from the sources; labelled as such._

## Fix

- Apply the Linux kernel stable fix that flushes and commits data before querying allocated ranges in smb3_simple_fallocate_range() (smb: client: flush and commit data before querying allocated ranges).
- Check the fixed kernel version for your branch in the NVD entry: `https://nvd.nist.gov/vuln/detail/CVE-2026-98684`

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98684

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_