Cloudanix VulnDB

CVE-2026-98685

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recent Linux bug could let leftover pieces of old file data show up in new sections of a file when copying across network shares, though the chance of this happening in practice appears very low.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw in cifs_remap_file_range() fails to invalidate the pagecache folio straddling the prior EOF when a clone-range operation extends the file, allowing mmap-dirtied data past the old EOF to become visible file content.

Why it matters to the business

Organizations using Linux SMB clients for file sharing face a low-probability risk of unintended data disclosure after recent publication with no known exploitation; patching urgency remains low given stable low EPSS and absence from KEV lists.

How an attack unfolds

An attacker with write access to an SMB share performs a clone-range operation that extends a target file; because the straddling folio at the old EOF is not discarded, previously mmap-dirtied content beyond the original EOF is now returned on subsequent reads.

How to fix it

Apply the upstream kernel commit that starts pagecache discard at the smaller of fstart and the old EOF; rebuild and deploy updated kernels to all affected Linux SMB clients.

How to confirm the fix worked

Confirm the fix is present by inspecting the cifs_remap_file_range implementation for the corrected discard-start logic or by verifying the running kernel contains the referenced commit after the 2026-10-18 patch date.

Typical attack path

  1. Obtain write access to an SMB/CIFS share from a Linux client
  2. Trigger cifs_remap_file_range via clone-range ioctl or equivalent on a file whose size will increase
  3. Read back the newly extended region to observe stale post-EOF pagecache contents

How to detect it

Search SMB client audit logs and kernel ring buffers for repeated cifs_remap_file_range calls followed by unexpected reads of regions beyond prior file sizes; correlate with mmap activity on the same inodes.

What your security team should do

  • Inventory Linux systems acting as SMB clients and schedule kernel updates within normal change windows
  • Monitor upstream stable kernel releases for backports of the pagecache discard fix
  • Review SMB file-sharing workflows for heavy use of clone-range or reflink operations to prioritize testing

The record

In the Linux kernel, the following vulnerability has been resolved: smb: client: discard post-EOF pagecache when extending a file via clone range cifs_remap_file_range() discarded the pagecache only for the folios overlapping the destination region, so when a clone extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Start the discard at the smaller of fstart and the old EOF. i_size is still old here, so nothing past the old EOF is flushed to the server.

Affected packages

Ecosystem Package Introduced Fixed