---
id: "CVE-2026-98682"
kind: "vulnerability"
aliases: ["CVE-2026-98682"]
title: "Linux kernel SMB client: destination cache can corrupt files after server-side copy"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["cifs", "kernel", "linux", "runtime", "smb", "windows-file-server"]
not_affected_if: ["local-filesystems-only", "no-smb-mounts"]
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:14+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98682", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel SMB client: destination cache can corrupt files after server-side copy

Linux kernel CIFS/SMB client copy and clone paths do not drain in-flight writeback on the destination file before a server-side copy, so stale cached data can overwrite the copied region. The sources describe file corruption, not a confirmed attacker-controlled read or code execution path.

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

## How to check

- `uname -r` on hosts that mount SMB shares with cifs, and compare against the kernel version that carries the upstream fix
- `lsmod | grep cifs` to confirm the cifs module is loaded at all
- unknown whether the sources list specific fixed kernel versions

## Fix

- Update the Linux kernel to a release that includes the upstream commit titled "smb: client: drain and invalidate before server-side copy/clone"
- unknown whether the sources name a fixed version

## Timeline

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

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

smb: client: drain and invalidate before server-side copy/clone

cifs_file_copychunk_range() and the clone (FICLONE) path of
cifs_remap_file_range() do not serialise the destination page cache
against the server-side copy the way the other server-side range
operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range()
and smb3_insert_range()) do.

cifs_file_copychunk_range() invalidates the destination range with
filemap_invalidate_inode(), which takes and drops the mapping's
invalidate_lock internally, so the lock is no longer held when the
copychunk ioctl is issued.  It also never drains in-flight netfs I/O on
the target.  The clone path never takes the invalidate_lock at all (only
i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not
drain outstanding I/O.

As a result an asynchronous destination writeback can complete after the
server-side copy/clone has run and reinstate stale data over the region
just written by the server, corrupting the file.  This is the same class
of corruption as commit d7d2adcd022b ("smb/client: flush dirty data
before punching a hole") and has been seen randomly in generic/363
against Windows Server.

Fix both paths to follow the established ordering: hold the target
mapping's invalidate_lock across the flush and invalidation of the
destination and the server ioctl, and call netfs_wait_for_outstanding_io()
on the target to drain in-flight writes before the ioctl is issued.  Only
the target inode's invalidate_lock is required, as the source is merely
flushed and not invalidated; i_rwsem (already held via
lock_two_nondirectories()) is acquired before the invalidate_lock,
matching the VFS lock ordering.  Since filemap_invalidate_inode() takes
that same lock internally, replace it with its own unmap/flush/invalidate
steps instead of calling it, and return early on a zero-length copy to
avoid a range underflow.

---

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