Live › vulnerability › CVE-2026-99137
Go to dashboardIn the Linux kernel's CIFS client, a truncate with no cached file handle could set the local inode size to 0 even when the server-side truncate never happened. The mismatch between local and server file size is the reported flaw; the sources do not describe an attacker gaining code execution or data access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Systems running a Linux kernel that includes the CIFS/SMB client and mount SMB shares for file access. The sources do not give affected kernel versions or say whether systems without CIFS mounts are exposed.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99137")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.