CVE-2026-72381 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free of fp->owner.name in durable handle owner check
Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory.
Commit 7ce4fc40018d ("ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized.
BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8
Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides in the linux kernel's ksmbd implementation where a use-after-free condition occurs during concurrent SMB2 durable reconnect operations. This flaw manifests when two simultaneous durable handle reconnects attempt to access the same persistent_id, creating a race condition between the comparison read of fp->owner.name and the subsequent kfree() operation within ksmbd_reopen_durable_fd(). The technical root cause stems from the independent lifetime of the fp->owner.name buffer which is allocated via kstrdup() and managed separately from the file pointer's reference count. This architectural disconnect allows one thread to read from freed memory while another thread simultaneously frees that same memory region, resulting in a slab-use-after-free error as identified by KASAN.
The vulnerability impacts the smb2_open function chain where ksmbd_vfs_compare_durable_owner() performs a strcmp() operation on the freed buffer, leading to potential system instability or exploitation. The race condition specifically occurs between the durable handle owner verification process and the file descriptor reopening sequence, with the former reading the buffer while the latter frees it without proper synchronization. This represents a classic race condition scenario where memory access timing creates a security vulnerability, classified under CWE-362 as a concurrent execution using shared data resource.
The operational impact of this vulnerability extends beyond simple system instability to potentially enable privilege escalation or denial of service attacks within network file sharing environments. Attackers could exploit the use-after-free condition to corrupt kernel memory structures, causing system crashes or potentially executing arbitrary code with kernel privileges. The vulnerability affects systems running the ksmbd SMB2 server implementation, particularly those handling concurrent durable reconnect operations, making it a significant concern for enterprise file servers and network infrastructure.
The fix implements proper serialization using fp->f_lock to synchronize access to the fp->owner.name buffer between the comparison read and reopen-free operations. While the existing global_ft.lock already protects the durable reconnect claim process, this specific race condition required per-open state synchronization since fp->owner.name represents individual file handle state rather than table-level operations. The solution maintains the existing teardown location after the reopen-success point to ensure that rollback scenarios still preserve owner.name for legitimate reconnect verification, thereby preserving system functionality while eliminating the memory safety violation.
This vulnerability demonstrates the challenges of managing shared kernel resources in high-concurrency environments and aligns with ATT&CK technique T1068 for privilege escalation through kernel exploits. The fix approach follows established security practices by implementing proper locking mechanisms to prevent race conditions, ensuring that memory access patterns respect the intended lifetime of allocated resources. The solution maintains backward compatibility while strengthening the security posture of the SMB2 implementation against concurrent access violations that could be exploited by malicious actors in networked environments.