CVE-2026-90171
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.
Leer descripción completaMostrar menos
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:
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:
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
Detalles técnicos trazas, registros y código del informe original
[ 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
[ 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 notationCVSS
NVD no ha asignado puntuación CVSS a esta CVE (habitual desde el cambio de política de abril de 2026).
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.20%
- Percentil entre todas las CVEs puntuadas: 9
- Fecha de la puntuación: 4/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-90171",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "dc691b91ad1677def14582a279e56fd943b52f94",
"lessThan": "8ea83ef0c40ec4463695e22bc9ae43e29bcfede7",
"versionType": "git"
},
{
"status": "affected",
"version": "dc691b91ad1677def14582a279e56fd943b52f94",
"lessThan": "db82fbe4bb68e68e4aef00ef5b79f92991d8ef8e",
"versionType": "git"
}
],
"programFiles": [
"fs/smb/smbdirect/socket.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "7.1"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "7.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "7.2.6",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"fs/smb/smbdirect/socket.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-09-17T17:17:10.650",
"references": [
{
"url": "https://git.kernel.org/stable/c/8ea83ef0c40ec4463695e22bc9ae43e29bcfede7",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/db82fbe4bb68e68e4aef00ef5b79f92991d8ef8e",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "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->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.\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] <TASK>\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->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\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"
}
],
"lastModified": "2026-09-17T17:17:10.650",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}