Cloudanix VulnDB

CVE-2026-89640

High · 7.1

CVSS

7.1

EPSS

0.1%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux network file-sharing code could let someone on the same computer corrupt or damage files being copied between shares.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Negative loff_t underflow in cifs_remap_file_range when len==0 and off>i_size corrupts ByteCount in FSCTL_DUPLICATE_EXTENTS_TO_FILE and inverts the range passed to filemap_write_and_wait_range; the off>=i_size check occurs after the ioctl is already issued.

Why it matters to the business

Local attackers can trigger data corruption or crashes during SMB/CIFS file-range operations, disrupting file-sharing services and risking integrity of shared data on affected Linux systems.

How an attack unfolds

A local user invokes the remap ioctl with len=0 and an offset past the end of the source file; the unsnapped i_size read produces a negative length that is sent to the server before the late bounds check can reject it.

How to fix it

Update to a kernel containing the fix that snapshots i_size_read once, rejects off>src_size with EINVAL, and treats off==src_size as a no-op before any ioctl is issued.

How to confirm the fix worked

Confirm the patched cifs.c contains the single i_size_read snapshot, the early EINVAL check, and the off==src_size no-op path; exercise the remap path with off>i_size and verify -EINVAL is returned without an SMB request being sent.

Typical attack path

  1. Obtain local shell or process execution on a Linux host using the CIFS client
  2. Locate or create a CIFS mount and source file
  3. Call cifs_remap_file_range (directly or via fallocate/ioctl) with offset greater than file size and len=0
  4. Observe corrupted request or kernel-side range inversion

How to detect it

Inspect kernel logs for cifs errors around FSCTL_DUPLICATE_EXTENTS_TO_FILE or negative-length remap attempts; correlate with local processes invoking fallocate or ioctl on CIFS mounts.

What your security team should do

  • Apply the corrected kernel to all CIFS client systems within the next patch cycle
  • Harden local access controls on hosts that mount untrusted SMB shares
  • Review application code that performs file-range clones for explicit length and offset validation

The record

In the Linux kernel, the following vulnerability has been resolved: cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0 With len == 0 (clone to EOF), the effective length is computed as: len = src_inode->i_size - off; If off > i_size, this is a negative loff_t, corrupting the ByteCount in the FSCTL_DUPLICATE_EXTENTS_TO_FILE request and inverting the range in filemap_write_and_wait_range(). The existing off >= i_size check fires only after the ioctl has already been sent. Snapshot i_size_read() once for both the bounds check and the length calculation, eliminating the TOCTOU and 32-bit torn-read risk. Reject off > src_size with -EINVAL. Treat off == src_size as a no-op, consistent with __generic_remap_file_range_prep().

Affected packages

Ecosystem Package Introduced Fixed