Cloudanix VulnDB

CVE-2026-98682

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how Linux handles certain network file copy operations can cause files to become corrupted without any obvious error.

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 CIFS client allows asynchronous writeback to complete after server-side copy/clone, reinstating stale data and corrupting the destination file range.

Why it matters to the business

Data corruption on files accessed through SMB/CIFS shares from Linux clients can silently damage file integrity during copy or clone operations, increasing risk of data loss or application errors in networked storage environments.

How an attack unfolds

An attacker with write access to a CIFS-mounted file issues concurrent writes while triggering server-side copychunk or FICLONE operations; the missing invalidate_lock and I/O drain allow post-copy writeback to overwrite the newly copied region with stale pages.

How to fix it

Apply the upstream kernel fix that holds invalidate_lock across flush/invalidation and calls netfs_wait_for_outstanding_io before issuing the server ioctl in both cifs_file_copychunk_range and the clone path of cifs_remap_file_range; upgrade to a kernel containing commit d7d2adcd022b-equivalent ordering for these paths.

How to confirm the fix worked

Confirm the presence of the updated cifs_file_copychunk_range and cifs_remap_file_range logic that acquires invalidate_lock before the server ioctl and drains netfs I/O; test with xfstests generic/363 against a Windows server target.

Typical attack path

  1. Mount a CIFS share from a vulnerable Linux kernel
  2. Perform overlapping writes and server-side copy/clone operations on the same file range
  3. Trigger asynchronous writeback that races with the copy
  4. Observe or exploit resulting file corruption

How to detect it

Monitor CIFS-mounted files for unexpected content changes after copy or clone operations; inspect kernel logs for page cache or netfs warnings around cifs operations; correlate with generic/363-style test failures.

What your security team should do

  • Prioritize kernel updates for systems mounting CIFS shares within the next patch cycle
  • Review CIFS usage in production workloads for exposure to concurrent copy operations
  • Add regression tests for file integrity after server-side copies on updated kernels

The record

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.

Affected packages

Ecosystem Package Introduced Fixed