{
  "cveId": "CVE-2026-90171",
  "url": "https://patchblox.com/security/cve/CVE-2026-90171",
  "summary": "CVE-2026-90171 is fixed in linux on 1 platform by DEBIAN-CVE-2026-90171 (version 7.2.6-1), released September 23, 2026. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  smb: smbdirect: release pending child sockets ou...",
  "description": "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\u0027s pending/ready child sockets while still holding the listener\u0027s handler lock, the \u0026id_priv-\u003Ehandler_mutex taken via rdma_lock_handler(), not sc-\u003Elisten.lock, and before the listener\u0027s own rdma_destroy_id(). That ordering has one real consequence and one cosmetic one.  The real one: smbdirect_socket_release() drops the child\u0027s last reference, which destroys the child\u0027s cm_id.  Doing that before the listener\u0027s rdma_destroy_id() lets _cma_cancel_listens(), running from the listener\u0027s _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\u002B0x1469/0x1560 [ 4758.911450] Read of size 1 at addr ffff88821c381db4 by task ksmbd.control/1652 [ 4758.913262] Call Trace: [ 4758.913267]  \u003CTASK\u003E [ 4758.913299]  __mutex_lock\u002B0x1469/0x1560 [ 4758.913408]  _cma_cancel_listens\u002B0x312/0x3b0 [ 4758.913413]  _destroy_id\u002B0x363/0xee0 [ 4758.913417]  smbdirect_socket_destroy_sync\u002B0x17d5/0x2440 [ 4758.913443]  smbdirect_socket_release\u002B0x124/0x230 [ 4758.913451]  ksmbd_rdma_stop_listening\u002B0x9f/0x190 [ 4758.913457]  ksmbd_conn_transport_destroy\u002B0x65/0x3c0 [ 4758.913463]  kill_server_store\u002B0x1fb/0x2b0 [ 4758.913501]  kernfs_fop_write_iter\u002B0x349/0x4d0 [ 4758.913507]  vfs_write\u002B0x5e7/0xc70 [ 4758.913528]  ksys_write\u002B0x12a/0x210 [ 4758.913541]  do_syscall_64\u002B0x135/0x460 [ 4758.913555]  entry_SYSCALL_64_after_hwframe\u002B0x77/0x7f  The cosmetic one: releasing a child recurses into smbdirect_socket_destroy(), which takes the child\u0027s own rdma_lock_handler() lock nested under the listener\u0027s.  The listener\u0027s and the child\u0027s cm_id are always different instances, so this cannot deadlock for real; the CM core itself nests a new connection id\u0027s handler_mutex under the listening id\u0027s 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\u002B #89 Not tainted [ 2424.582548] -------------------------------------------- [ 2424.584500] ksmbd.control/8854 is trying to acquire lock: [ 2424.586817] ffff888102303c20 (\u0026id_priv-\u003Ehandler_mutex){\u002B.\u002B.}-{4:4}, at: smbdirect_socket_destroy_sync\u002B0xc39/0x2440 [ 2424.590590] [ 2424.590590] but task is already holding lock: [ 2424.591601] ffff888102046c20 (\u0026id_priv-\u003Ehandler_mutex){\u002B.\u002B.}-{4:4}, at: smbdirect_socket_destroy_sync\u002B0xc39/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(\u0026id_priv-\u003Ehandler_mutex); [ 2424.601836]   lock(\u0026id_priv-\u003Ehandler_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\u0027s 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\u0027s cm_id has been destroyed and its handler lock dropped.  The children are independent sockets whose teardown needs neither the listener\u0027s 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\u0027s runtime operand value together with its PC (the default arm mixes them as pc\u2295val) 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",
  "published": "2026-09-17T17:17:10Z",
  "severity": "",
  "epss": 0.00198,
  "epssPercentile": 0.09557,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.2.6-1",
      "fix": "DEBIAN-CVE-2026-90171",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-90171",
      "released": "2026-09-23T19:19:02Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T00:53:09Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}