CVE-2026-90171: smb: smbdirect: release pending child sockets outside the handler lock

In the Linux kernel, the following vulnerability has been resolved:

smb: smbdirect: release pending child sockets outside the handler lock

smbdirectsocketdestroy() releases the listener's pending/ready child sockets while still holding the listener's handler lock, the &idpriv->handlermutex taken via rdmalockhandler(), not sc->listen.lock, and before the listener's own rdmadestroyid(). That ordering has one real consequence and one cosmetic one.

The real one: smbdirectsocketrelease() drops the child's last reference, which destroys the child's cmid. Doing that before the listener's rdmadestroyid() lets cmacancellistens(), running from the listener's destroyid(), walk an already freed child idpriv, which KASAN catches as a slab-use-after-free during listener shutdown:

[ 4758.909130] BUG: KASAN: slab-use-after-free in mutexlock+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] mutexlock+0x1469/0x1560 [ 4758.913408] cmacancellistens+0x312/0x3b0 [ 4758.913413] destroyid+0x363/0xee0 [ 4758.913417] smbdirectsocketdestroysync+0x17d5/0x2440 [ 4758.913443] smbdirectsocketrelease+0x124/0x230 [ 4758.913451] ksmbdrdmastoplistening+0x9f/0x190 [ 4758.913457] ksmbdconntransportdestroy+0x65/0x3c0 [ 4758.913463] killserverstore+0x1fb/0x2b0 [ 4758.913501] kernfsfopwriteiter+0x349/0x4d0 [ 4758.913507] vfswrite+0x5e7/0xc70 [ 4758.913528] ksyswrite+0x12a/0x210 [ 4758.913541] dosyscall64+0x135/0x460 [ 4758.913555] entrySYSCALL64afterhwframe+0x77/0x7f

The cosmetic one: releasing a child recurses into smbdirectsocketdestroy(), which takes the child's own rdmalockhandler() lock nested under the listener's. The listener's and the child's cmid are always different instances, so this cannot deadlock for real; the CM core itself nests a new connection id's handlermutex under the listening id's in cmaibreqhandler(). 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 (&idpriv->handlermutex){+.+.}-{4:4}, at: smbdirectsocketdestroysync+0xc39/0x2440 [ 2424.590590] [ 2424.590590] but task is already holding lock: [ 2424.591601] ffff888102046c20 (&idpriv->handlermutex){+.+.}-{4:4}, at: smbdirectsocketdestroysync+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(&idpriv->handlermutex); [ 2424.601836] lock(&idpriv->handlermutex); [ 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 CONNECTREQUEST cannot add more, but defer the actual smbdirectsocketrelease() calls until after the listener's cmid has been destroyed and its handler lock dropped. The children are independent sockets whose teardown needs neither the listener's handler lock nor its cmid.

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