{"id":"CVE-2026-90171","summary":"smb: smbdirect: release pending child sockets outside the handler lock","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: smbdirect: release pending child sockets outside the handler lock\n\nsmbdirect_socket_destroy() releases the listener's pending/ready child\nsockets while still holding the listener's handler lock, the\n&id_priv-\u003ehandler_mutex taken via rdma_lock_handler(), not\nsc-\u003elisten.lock, and before the listener's own rdma_destroy_id().\nThat ordering has one real consequence and one cosmetic one.\n\nThe 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:\n\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]  \u003cTASK\u003e\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\n\nThe 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:\n\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-\u003ehandler_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-\u003ehandler_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-\u003ehandler_mutex);\n[ 2424.601836]   lock(&id_priv-\u003ehandler_mutex);\n[ 2424.602590]\n[ 2424.602590]  *** DEADLOCK ***\n[ 2424.602590]\n[ 2424.604512]  May be due to missing lock nesting notation\n\nSplice 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.\n\nFound 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⊕val) so that a new operand value at a known\nsite counts as new coverage.\n\n[1] https://lwn.net/Articles/1077606/\n[2] https://github.com/yskzalloc/kcov-dataflow","modified":"2026-09-19T03:47:28.760583849Z","published":"2026-09-17T16:06:59.150Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90171.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/8ea83ef0c40ec4463695e22bc9ae43e29bcfede7"},{"type":"WEB","url":"https://git.kernel.org/stable/c/db82fbe4bb68e68e4aef00ef5b79f92991d8ef8e"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90171.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90171"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"dc691b91ad1677def14582a279e56fd943b52f94"},{"fixed":"8ea83ef0c40ec4463695e22bc9ae43e29bcfede7"},{"fixed":"db82fbe4bb68e68e4aef00ef5b79f92991d8ef8e"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90171.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.1.0"},{"fixed":"7.2.6"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90171.json"}}],"schema_version":"1.9.0"}