UBUNTU-CVE-2026-99137: Medium severity vulnerability
In the Linux kernel, the following vulnerability has been resolved: cifs: don't update isize in cifsdotruncate without a cached handle If findwritablefile() returns null, cifsfileflush will return 0 without issuing setfilesize, and the outer 'if (!rc)' block will set isize to 0 before telling the server to truncate. If the cifsopen() then fails, the inode will have size 0, while the server file is unchanged. Move the netfsresizefile() and cifssetsize() into the 'if (cfile)', so they only run after a successful setfilesize. In the no-handle else branch, evict stale pages with truncateinodepages before the OTRUNC open to dispose of old cache pages, and let the open response set the isize.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In cifs_do_truncate, when no cached writable handle is available, evict stale pages with truncate_inode_pages before the O_TRUNC open; only call netfs_resize_file() and cifs_setsize() inside the cfile branch after a successful set_file_size.
Frequently Asked Questions
What condition triggers the inconsistent file-size state?
The issue occurs when CIFS truncation has no cached writable file handle because find_writable_file() returns null, and the subsequent cifs_open() operation fails. In that path, the local inode size can be set to 0 even though the server-side file was not truncated.
What is the practical impact of the inconsistency?
A client can retain a local inode size of zero while the corresponding server file remains unchanged. Stale cached pages may also remain until they are evicted.
How does the fix prevent this?
The fix performs netfs_resize_file() and cifs_setsize() only when a cached file handle is present and set_file_size has succeeded. When no handle exists, it evicts stale pages before the O_TRUNC open and relies on the open response to set the inode size.