CVE-2026-90171 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
smb: smbdirect: release pending child sockets outside the handler lock
smbdirect_socket_destroy() releases the listener's pending/ready child sockets while still holding the listener's handler lock, the &id_priv->handler_mutex taken via rdma_lock_handler(), not sc->listen.lock, and before the listener's own rdma_destroy_id(). That ordering has one real consequence and one cosmetic one.
The real one: smbdirect_socket_release() drops the child's last reference, which destroys the child's cm_id. Doing that before the listener's rdma_destroy_id() lets _cma_cancel_listens(), running from the listener's _destroy_id(), walk an already freed child id_priv, which KASAN catches as a slab-use-after-free during listener shutdown:
[ 4758.909130] BUG: KASAN: slab-use-after-free in __mutex_lock+0x1469/0x1560
[ 4758.911450] Read of size 1 at addr ffff88821c381db4 by task ksmbd.control/1652
[ 4758.913262] Call Trace:
[ 4758.913267] <TASK>
[ 4758.913299] __mutex_lock+0x1469/0x1560
[ 4758.913408] _cma_cancel_listens+0x312/0x3b0
[ 4758.913413] _destroy_id+0x363/0xee0
[ 4758.913417] smbdirect_socket_destroy_sync+0x17d5/0x2440
[ 4758.913443] smbdirect_socket_release+0x124/0x230
[ 4758.913451] ksmbd_rdma_stop_listening+0x9f/0x190
[ 4758.913457] ksmbd_conn_transport_destroy+0x65/0x3c0
[ 4758.913463] kill_server_store+0x1fb/0x2b0
[ 4758.913501] kernfs_fop_write_iter+0x349/0x4d0
[ 4758.913507] vfs_write+0x5e7/0xc70
[ 4758.913528] ksys_write+0x12a/0x210
[ 4758.913541] do_syscall_64+0x135/0x460
[ 4758.913555] entry_SYSCALL_64_after_hwframe+0x77/0x7f
The cosmetic one: releasing a child recurses into smbdirect_socket_destroy(), which takes the child's own rdma_lock_handler() lock nested under the listener's. The listener's and the child's cm_id are always different instances, so this cannot deadlock for real; the CM core itself nests a new connection id's handler_mutex under the listening id's in cma_ib_req_handler(). But lockdep only sees one lock class, reports possible recursive locking, and then disables itself, hiding real locking bugs for the rest of the run:
[ 2424.579653] WARNING: possible recursive locking detected
[ 2424.581180] 7.1.0-next-20260623+ #89 Not tainted
[ 2424.582548] --------------------------------------------
[ 2424.584500] ksmbd.control/8854 is trying to acquire lock:
[ 2424.586817] ffff888102303c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.590590]
[ 2424.590590] but task is already holding lock:
[ 2424.591601] ffff888102046c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39/0x2440
[ 2424.594178]
[ 2424.594178] other info that might help us debug this:
[ 2424.596634] Possible unsafe locking scenario:
[ 2424.596634]
[ 2424.598841] CPU0
[ 2424.599765] ----
[ 2424.600695] lock(&id_priv->handler_mutex);
[ 2424.601836] lock(&id_priv->handler_mutex);
[ 2424.602590]
[ 2424.602590] *** DEADLOCK ***
[ 2424.602590]
[ 2424.604512] May be due to missing lock nesting notation
Splice the pending/ready children onto a local list under the listener's listen.lock, while the handler lock is held so a concurrent CM CONNECT_REQUEST cannot add more, but defer the actual smbdirect_socket_release() calls until after the listener's cm_id has been destroyed and its handler lock dropped. The children are independent sockets whose teardown needs neither the listener's handler lock nor its cm_id.
Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a
kcov-dataflow [1] coverage vector: it folds each instrumented
comparison/argument's runtime operand value together with its PC (the default arm mixes them as pc⊕val) so that a new operand value at a known site counts as new coverage.
[1] https://lwn.net/Articles/1077606/
[2] https://github.com/yskzalloc/kcov-dataflow
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's SMB Direct implementation involves a critical use-after-free condition and potential lock dependency issues within the smbdirect_socket_destroy function. This flaw occurs during the teardown process of RDMA (Remote Direct Memory Access) connections, specifically when releasing pending or ready child sockets associated with a listener socket. The core issue stems from an incorrect ordering of operations where the code attempts to release these child sockets while still holding the listener's handler mutex, obtained via rdma_lock_handler(). This sequence leads to premature destruction of child connection identifiers before the parent listener's identifier is properly destroyed, creating a window for memory corruption and locking anomalies.
The primary technical consequence of this vulnerability is a slab-use-after-free error detected by Kernel Address Sanitizer (KASAN). When smbdirect_socket_release drops the last reference to a child socket, it triggers the destruction of that child's cm_id. However, because this happens before the listener's rdma_destroy_id completes, the subsequent call to _cma_cancel_listens walks through an already freed child id_priv structure. This results in invalid memory access during mutex locking operations within the connection manager core. The stack trace indicates that the crash occurs deep within the kernel's synchronization primitives as it attempts to lock a mutex associated with corrupted or freed memory structures, leading to system instability and potential denial of service conditions for services relying on SMB Direct connectivity.
Beyond the immediate use-after-free risk, the vulnerability presents a secondary issue related to locking semantics. The current implementation causes recursive acquisition of the handler_mutex because releasing a child socket recursively invokes smbdirect_socket_destroy again, which attempts to acquire its own rdma_lock_handler(). Although lockdep identifies this as a possible deadlock scenario due to missing lock nesting notation, it does not represent a true logical deadlock since the listener and child cm_ids are distinct instances. Nevertheless, this false positive causes lockdep to disable itself for the remainder of the execution cycle, thereby masking other genuine locking bugs that could lead to actual deadlocks or race conditions in concurrent environments.
The operational impact of these flaws is significant for systems utilizing KSMBD over RDMA networks. The use-after-free can be triggered during server shutdown or connection teardown sequences, potentially allowing a local user with sufficient privileges to crash the kernel or exploit memory corruption if additional attack vectors are present. Furthermore, the disruption of lockdep's functionality reduces the effectiveness of static and dynamic analysis tools in detecting concurrency issues, leaving the system vulnerable to subtle race conditions that may manifest under heavy load or specific timing scenarios. This affects the reliability and security posture of network file sharing services implemented via SMB Direct on Linux kernels affected by this issue.
The resolution involves restructuring the socket release logic to ensure proper lifecycle management of RDMA identifiers. The fix requires splicing pending and ready child sockets onto a local list while holding only the listener's listen.lock, which prevents concurrent connection requests from adding new children during teardown. Crucially, the actual smbdirect_socket_release calls are deferred until after the listener's cm_id has been fully destroyed and its handler lock released. This ensures that child socket teardown occurs independently of the parent listener's synchronization context, eliminating both the use-after-free condition and the recursive locking problem. By decoupling the destruction order from the holding of the handler mutex, the kernel maintains memory safety and preserves the integrity of debugging tools like lockdep.
From a vulnerability classification perspective, this issue aligns with CWE-416: Use After Free, as it involves accessing memory after it has been freed due to improper resource management ordering. It also relates to CWE-830: Inclusion of Functionality Within Multiple Trust Domains in the context of locking hierarchies where different trust levels or synchronization contexts are improperly nested. In terms of MITRE ATT&CK, this vulnerability could be leveraged for Defense Evasion by disrupting security monitoring tools that rely on kernel debuggers and lock dependency checkers to detect malicious activity. It may also facilitate Privilege Escalation if the use-after-free condition can be exploited to execute arbitrary code within the kernel space during the brief window of invalid memory access.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects the smbdirect_socket_destroy logic. Administrators should ensure their systems are updated with kernels containing this fix, particularly those running KSMBD services over RDMA interfaces. For environments where immediate patching is not feasible, disabling SMB Direct or restricting access to RDMA-capable network adapters can reduce the attack surface. Additionally, enabling KASAN in development and testing environments helps identify similar memory safety issues early in the software lifecycle. Continuous integration pipelines should incorporate fuzzing tools like ksmbdzzer that utilize kcov-dataflow coverage metrics to detect edge cases in connection handling code before deployment.