Cloudanix VulnDB

CVE-2026-99137

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recent Linux bug can make files on network shares appear empty or the wrong size on the local machine, risking data problems until the system is updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Medium

What it actually does

The flaw causes cifs_do_truncate to set i_size to zero on the local inode when find_writable_file returns null and a subsequent cifs_open fails, while the remote server file remains unchanged, producing a persistent size mismatch and stale cache pages.

Why it matters to the business

Linux systems mounting CIFS/SMB shares can experience silent file-size corruption or application-visible data inconsistencies on recently published kernels, increasing operational risk for file-serving workloads until patches are applied.

How an attack unfolds

An attacker with local access to a CIFS-mounted filesystem issues truncate or open-with-truncate operations that hit the no-handle path; the buggy size-update logic then writes i_size=0 locally before any server-side change, and a failed open leaves the inode in the corrupted state.

How to fix it

Upgrade to a kernel containing the corrected cifs truncate logic that confines netfs_resize_file and cifs_setsize to the successful cfile branch and performs truncate_inode_pages in the no-handle path before any O_TRUNC open.

How to confirm the fix worked

Confirm the running kernel contains the fix by inspecting the cifs_do_truncate and cifs_file_flush functions for the moved size-update block and the added truncate_inode_pages call; re-test truncate behavior on CIFS mounts after the update.

Typical attack path

  1. Mount a remote CIFS share on a vulnerable kernel
  2. Trigger file operations that call cifs_file_flush without a cached writable handle
  3. Force or wait for cifs_open to fail after the erroneous size assignment
  4. Observe local inode reporting size zero while server file is untouched

How to detect it

Search kernel logs and audit trails for cifs truncate or set_file_size entries around the time of file-size anomalies on SMB mounts; correlate with failed cifs_open attempts and unexpected i_size changes reported by stat or application errors.

What your security team should do

  • Prioritize kernel updates for all systems with CIFS mounts given the three-day publication window
  • Temporarily restrict CIFS write access or switch to alternative protocols on high-value hosts until patched
  • Add kernel-version checks to vulnerability scanners and asset inventories

The record

In the Linux kernel, the following vulnerability has been resolved: cifs: don't update i_size in cifs_do_truncate without a cached handle If find_writable_file() returns null, cifs_file_flush will return 0 without issuing set_file_size, and the outer 'if (!rc)' block will set i_size to 0 before telling the server to truncate. If the cifs_open() then fails, the inode will have size 0, while the server file is unchanged. Move the netfs_resize_file() and cifs_setsize() into the 'if (cfile)', so they only run after a successful set_file_size. In the no-handle else branch, evict stale pages with truncate_inode_pages before the O_TRUNC open to dispose of old cache pages, and let the open response set the i_size.

Affected packages

Ecosystem Package Introduced Fixed