UBUNTU-CVE-2026-99111: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix data corruption with concurrent writes and OTRUNC cifsdotruncate() flushes dirty pages with filemapwriteandwait() and truncates the file on the server, but in the old code both operations ran without holding irwsem or invalidatelock. A concurrent buffered write via netfsperformwrite() -- which only needs irwsem shared -- could dirty new pages after the flush but before the local truncation, and those pages would be silently discarded by cifssetsize() -> truncatepagecache(). Fix by acquiring inodelock (exclusive irwsem) and filemapinvalidatelock at the top of cifsdotruncate(), so the entire flush-truncate-resize sequence is atomic with respect to: - buffered writes (blocked by exclusive irwsem, since netfsstartiowrite takes irwsem shared), - read page faults (blocked by exclusive invalidatelock, since filemapfault takes it shared), - writeback collection (blocked by netfswbbegin/netfswbend around the server truncate and local resize, since netfswritepages also acquires the wb lock).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Acquire inode_lock (exclusive i_rwsem) and filemap_invalidate_lock at the top of cifs_do_truncate() so the flush-truncate-resize sequence is atomic with respect to buffered writes and read page faults.
Linux kernel SMB client cifs_do_truncate() inode_lock and filemap_invalidate_lock = acquired exclusively at the top of cifs_do_truncate()
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using the affected Ubuntu kernel packages and accessing files through the SMB/CIFS client are exposed when a file can be truncated while buffered writes to the same file occur concurrently.
What conditions are required for data corruption?
A truncate operation must race with a concurrent buffered write. In the vulnerable sequence, the write can dirty pages after dirty pages are flushed but before the client resizes its local page cache, causing those newly written pages to be discarded.
Does this require an attacker to access the SMB server?
The described condition is a client-side concurrency issue in the Linux SMB/CIFS client. The provided information does not state that server compromise or special server behavior is required; the relevant operation is concurrent truncation and buffered writing of the same file from the client.
What is the practical impact?
Concurrent writes can be silently lost during a truncate operation, resulting in file data corruption. The description does not indicate code execution, privilege escalation, or disclosure impacts.