DEBIAN-CVE-2026-90171

See a problem?
Please try reporting it to the source first.
Source
https://security-tracker.debian.org/tracker/CVE-2026-90171
Import Source
https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-90171.json
JSON Data
https://api.osv.dev/v1/vulns/DEBIAN-CVE-2026-90171
Upstream
Published
2026-09-17T17:17:10Z
Modified
2026-09-18T05:01:10Z
Summary
[none]
Details

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] [ 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

References

Affected packages

Debian:14 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source&distro=forky

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected

Affected versions

6.*
6.12.38-1
6.12.41-1
6.12.43-1~bpo12+1
6.12.43-1
6.12.48-1
6.12.57-1~bpo12+1
6.12.57-1
6.12.63-1~bpo12+1
6.12.63-1
6.12.69-1~bpo12+1
6.12.69-1
6.12.73-1~bpo12+1
6.12.73-1
6.12.74-1
6.12.74-2~bpo12+1
6.12.74-2
6.12.85-1~bpo12+1
6.12.85-1
6.12.86-1~bpo12+1
6.12.86-1
6.12.88-1~bpo12+1
6.12.88-1
6.12.90-1~bpo12+1
6.12.90-1
6.12.90-2~bpo12+1
6.12.90-2
6.12.94-1~bpo12+1
6.12.94-1
6.12.95-1~bpo12+1
6.12.95-1
6.12.96-1
6.12.100-1
6.12.101-1
6.12.105-1
6.12.107-1
6.13~rc6-1~exp1
6.13~rc7-1~exp1
6.13.2-1~exp1
6.13.3-1~exp1
6.13.4-1~exp1
6.13.5-1~exp1
6.13.6-1~exp1
6.13.7-1~exp1
6.13.8-1~exp1
6.13.9-1~exp1
6.13.10-1~exp1
6.13.11-1~exp1
6.14.3-1~exp1
6.14.5-1~exp1
6.14.6-1~exp1
6.15~rc7-1~exp1
6.15-1~exp1
6.15.1-1~exp1
6.15.2-1~exp1
6.15.3-1~exp1
6.15.4-1~exp1
6.15.5-1~exp1
6.15.6-1~exp1
6.16~rc7-1~exp1
6.16-1~exp1
6.16.1-1~exp1
6.16.3-1~bpo13+1
6.16.3-1
6.16.5-1
6.16.6-1
6.16.7-1
6.16.8-1
6.16.9-1
6.16.10-1
6.16.11-1
6.16.12-1~bpo13+1
6.16.12-1
6.16.12-2
6.17.2-1~exp1
6.17.5-1~exp1
6.17.6-1
6.17.7-1
6.17.7-2
6.17.8-1~bpo13+1
6.17.8-1
6.17.9-1
6.17.10-1
6.17.11-1
6.17.12-1
6.17.13-1~bpo13+1
6.17.13-1
6.18~rc4-1~exp1
6.18~rc4-1~exp2
6.18~rc5-1~exp1
6.18~rc6-1~exp1
6.18~rc7-1~exp1
6.18.1-1~exp1
6.18.2-1~exp1
6.18.3-1
6.18.5-1~bpo13+1
6.18.5-1
6.18.8-1
6.18.9-1~bpo13+1
6.18.9-1
6.18.10-1
6.18.12-1~bpo13+1
6.18.12-1
6.18.13-1
6.18.14-1
6.18.15-1~bpo13+1
6.18.15-1
6.19~rc4-1~exp1
6.19~rc5-1~exp1
6.19~rc6-1~exp1
6.19~rc7-1~exp1
6.19~rc8-1~exp1
6.19-1~exp1
6.19.2-1~exp1
6.19.3-1~exp1
6.19.4-1~exp1
6.19.5-1~exp1
6.19.6-1
6.19.6-2~bpo13+1
6.19.6-2
6.19.8-1~bpo13+1
6.19.8-1
6.19.10-1~bpo13+1
6.19.10-1
6.19.11-1~bpo13+1
6.19.11-1
6.19.12-1
6.19.13-1~bpo13+1
6.19.13-1
6.19.14-1~bpo13+1
6.19.14-1
7.*
7.0-1~exp1
7.0.1-1~exp1
7.0.3-1
7.0.4-1~bpo13+1
7.0.4-1
7.0.7-1~bpo13+1
7.0.7-1
7.0.9-1~bpo13+1
7.0.9-1
7.0.10-1~bpo13+1
7.0.10-1
7.0.12-1
7.0.12-2~bpo13+1
7.0.12-2
7.0.13-1~bpo13+1
7.0.13-1
7.0.14-1
7.1~rc2-1~exp1
7.1~rc3-1~exp1
7.1~rc4-1~exp1
7.1~rc4-1~exp2
7.1~rc5-1~exp1
7.1~rc7-1~exp1
7.1.1-1~exp1
7.1.2-1~exp1
7.1.3-1~bpo13+1
7.1.3-1
7.1.3-1+sunvdc
7.1.4-1
7.1.5-1
7.1.6-1
7.1.7-1~bpo13+1
7.1.7-1
7.1.8-1~bpo13+1
7.1.8-1
7.1.8-2
7.1.9-1
7.1.9-1+sparc64
7.1.10-1
7.1.12-1
7.1.13-1
7.2~rc3-1~exp1
7.2~rc5-1~exp1
7.2~rc7-1~exp1
7.2.2-1~exp1
7.2.3-1~exp1
7.2.6-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Database specific

source 
"https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-90171.json"