In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
smb: smbdirect: release pending child sockets outside the handler lock<\/p>\n
smbdirect_socket_destroy() releases the listener’s pending\/ready child
\nsockets while still holding the listener’s handler lock, the
\n&id_priv->handler_mutex taken via rdma_lock_handler(), not
\nsc->listen.lock, and before the listener’s own rdma_destroy_id().
\nThat ordering has one real consequence and one cosmetic one.<\/p>\n
The real one: smbdirect_socket_release() drops the child’s last
\nreference, which destroys the child’s cm_id. Doing that before the
\nlistener’s rdma_destroy_id() lets _cma_cancel_listens(), running from
\nthe listener’s _destroy_id(), walk an already freed child id_priv,
\nwhich KASAN catches as a slab-use-after-free during listener shutdown:<\/p>\n
[ 4758.909130] BUG: KASAN: slab-use-after-free in __mutex_lock+0x1469\/0x1560
\n[ 4758.911450] Read of size 1 at addr ffff88821c381db4 by task ksmbd.control\/1652
\n[ 4758.913262] Call Trace:
\n[ 4758.913267]
\n[ 4758.913299] __mutex_lock+0x1469\/0x1560
\n[ 4758.913408] _cma_cancel_listens+0x312\/0x3b0
\n[ 4758.913413] _destroy_id+0x363\/0xee0
\n[ 4758.913417] smbdirect_socket_destroy_sync+0x17d5\/0x2440
\n[ 4758.913443] smbdirect_socket_release+0x124\/0x230
\n[ 4758.913451] ksmbd_rdma_stop_listening+0x9f\/0x190
\n[ 4758.913457] ksmbd_conn_transport_destroy+0x65\/0x3c0
\n[ 4758.913463] kill_server_store+0x1fb\/0x2b0
\n[ 4758.913501] kernfs_fop_write_iter+0x349\/0x4d0
\n[ 4758.913507] vfs_write+0x5e7\/0xc70
\n[ 4758.913528] ksys_write+0x12a\/0x210
\n[ 4758.913541] do_syscall_64+0x135\/0x460
\n[ 4758.913555] entry_SYSCALL_64_after_hwframe+0x77\/0x7f<\/p>\n
The cosmetic one: releasing a child recurses into
\nsmbdirect_socket_destroy(), which takes the child’s own
\nrdma_lock_handler() lock nested under the listener’s. The listener’s
\nand the child’s cm_id are always different instances, so this cannot
\ndeadlock for real; the CM core itself nests a new connection id’s
\nhandler_mutex under the listening id’s in cma_ib_req_handler(). But
\nlockdep only sees one lock class, reports possible recursive locking,
\nand then disables itself, hiding real locking bugs for the rest of the
\nrun:<\/p>\n
[ 2424.579653] WARNING: possible recursive locking detected
\n[ 2424.581180] 7.1.0-next-20260623+ #89 Not tainted
\n[ 2424.582548] ——————————————–
\n[ 2424.584500] ksmbd.control\/8854 is trying to acquire lock:
\n[ 2424.586817] ffff888102303c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39\/0x2440
\n[ 2424.590590]
\n[ 2424.590590] but task is already holding lock:
\n[ 2424.591601] ffff888102046c20 (&id_priv->handler_mutex){+.+.}-{4:4}, at: smbdirect_socket_destroy_sync+0xc39\/0x2440
\n[ 2424.594178]
\n[ 2424.594178] other info that might help us debug this:
\n[ 2424.596634] Possible unsafe locking scenario:
\n[ 2424.596634]
\n[ 2424.598841] CPU0
\n[ 2424.599765] —-
\n[ 2424.600695] lock(&id_priv->handler_mutex);
\n[ 2424.601836] lock(&id_priv->handler_mutex);
\n[ 2424.602590]
\n[ 2424.602590] *** DEADLOCK ***
\n[ 2424.602590]
\n[ 2424.604512] May be due to missing lock nesting notation<\/p>\n
Splice the pending\/ready children onto a local list under the
\nlistener’s listen.lock, while the handler lock is held so a concurrent
\nCM CONNECT_REQUEST cannot add more, but defer the actual
\nsmbdirect_socket_release() calls until after the listener’s cm_id has
\nbeen destroyed and its handler lock dropped. The children are
\nindependent sockets whose teardown needs neither the listener’s
\nhandler lock nor its cm_id.<\/p>\n
Found with ksmbdzzer [2], a KSMBD fuzzer that drives libFuzzer with a
\nkcov-dataflow [1] coverage vector: it folds each instrumented
\ncomparison\/argument’s runtime operand value together with its PC (the
\ndefault arm mixes them as pc\u2295val) so that a new operand value at a known
\nsite counts as new coverage.<\/p>\n
[1] https:\/\/lwn.net\/Articles\/1077606\/
\n[2] https:\/\/github.com\/yskzalloc\/kcov-dataflow<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
smb: smbdirect: release pending child sockets outside the handler lock<\/p>\n
smbdirect_socket_destroy() releases the listener’s pending\/<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-25580","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/25580","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25580"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25580"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25580"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}