GHSA-PQJ5-PGR6-PMV4

Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-18 18:31
VLAI
Details

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

smb: smbdirect: destroy QP before mem pools on accept failure

On the rdma_accept_failed error path of smbdirect_accept_connect_request(), the receive io posted just above is owned by the QP (recv_io is set to NULL after a successful post). The error path fell through to smbdirect_connection_destroy_mem_pools() before smbdirect_connection_destroy_qp(), so the mem pools and the recv_io slab cache were destroyed while that recv_io was still outstanding on the QP.

The drain in smbdirect_connection_destroy_qp() (ib_drain_qp()) is what runs the recv completion that returns the recv_io to the free list, so destroying the pools first leaves the object outstanding at kmem_cache_destroy() time ("Slab cache still has objects") and later frees it into an already-destroyed mempool (mempool_free_bulk NULL-pointer dereference).

Give rdma_accept_failed its own teardown that drains the QP first, then destroys the mem pools, and returns. The remaining labels (post_recv_io_failed onward) run before the recv_io was ever posted, so they keep the mem-pools-then-qp order.

The outstanding recv_io at kmem_cache_destroy() time:

[ 3487.344647] ============================================================================= [ 3487.349942] BUG smbdirect_recv_io_cache_ffff88811ba99000 (Not tainted): Objects remaining on __kmem_cache_shutdown() [ 3487.356078] ----------------------------------------------------------------------------- [ 3487.356078] [ 3487.356738] Object 0xffff8881511c3440 @offset=13376 [ 3487.358464] Allocated in mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254 [ 3487.361197] mempool_alloc_noprof+0x18c/0x290 [ 3487.361542] smbdirect_connection_create_mem_pools+0x405/0x780 [ 3487.361972] smbdirect_accept_connect_request+0x5a8/0x1b80 [ 3487.362359] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3487.362779] cma_cm_event_handler+0x9c/0x230 [ 3487.363096] cma_ib_req_handler+0x2682/0x45d0 [ 3487.363414] cm_process_work+0x56/0x3d0 [ 3487.363676] cm_work_handler+0x8a0e/0xd000 [ 3487.367496] process_scheduled_works+0xa07/0x13a0 [ 3487.367859] worker_thread+0x7c9/0xc80 [ 3487.368148] kthread+0x341/0x430 [ 3487.368407] ret_from_fork+0x3a8/0x7a0 [ 3487.368704] ret_from_fork_asm+0x1a/0x30 [ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2) [ 3487.372840] ------------[ cut here ]------------ [ 3487.373195] WARNING: mm/slub.c:1244 at __slab_err+0x1a/0x30, CPU#6: kworker/6:84/22254 [ 3487.373759] Modules linked in: [ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B 7.1.0-next-20260623+ #88 PREEMPT(lazy) [ 3487.374778] Tainted: [B]=BAD_PAGE [ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3487.378515] Workqueue: ib_cm cm_work_handler [ 3487.378820] RIP: 0010:__slab_err+0x1a/0x30 [ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093 [ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80 [ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080 [ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410 [ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210 [ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300 [ 3487.388932] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000 [ 3487.389529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0 [ 3487.390440] PKRU: 55555554 [ 3487.390641] Call Trace: [ 3487.390826] [ 3 ---truncated---

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-90172"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T17:17:10Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: smbdirect: destroy QP before mem pools on accept failure\n\nOn the rdma_accept_failed error path of\nsmbdirect_accept_connect_request(), the receive io posted just above is\nowned by the QP (recv_io is set to NULL after a successful post).  The\nerror path fell through to smbdirect_connection_destroy_mem_pools()\nbefore smbdirect_connection_destroy_qp(), so the mem pools and the\nrecv_io slab cache were destroyed while that recv_io was still\noutstanding on the QP.\n\nThe drain in smbdirect_connection_destroy_qp() (ib_drain_qp()) is what\nruns the recv completion that returns the recv_io to the free list, so\ndestroying the pools first leaves the object outstanding at\nkmem_cache_destroy() time (\"Slab cache still has objects\") and later\nfrees it into an already-destroyed mempool (mempool_free_bulk\nNULL-pointer dereference).\n\nGive rdma_accept_failed its own teardown that drains the QP first, then\ndestroys the mem pools, and returns.  The remaining labels\n(post_recv_io_failed onward) run before the recv_io was ever posted, so\nthey keep the mem-pools-then-qp order.\n\nThe outstanding recv_io at kmem_cache_destroy() time:\n\n[ 3487.344647] =============================================================================\n[ 3487.349942] BUG smbdirect_recv_io_cache_ffff88811ba99000 (Not tainted): Objects remaining on __kmem_cache_shutdown()\n[ 3487.356078] -----------------------------------------------------------------------------\n[ 3487.356078]\n[ 3487.356738] Object 0xffff8881511c3440 @offset=13376\n[ 3487.358464] Allocated in mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254\n[ 3487.361197]  mempool_alloc_noprof+0x18c/0x290\n[ 3487.361542]  smbdirect_connection_create_mem_pools+0x405/0x780\n[ 3487.361972]  smbdirect_accept_connect_request+0x5a8/0x1b80\n[ 3487.362359]  smbdirect_listen_rdma_event_handler+0x1579/0x1b90\n[ 3487.362779]  cma_cm_event_handler+0x9c/0x230\n[ 3487.363096]  cma_ib_req_handler+0x2682/0x45d0\n[ 3487.363414]  cm_process_work+0x56/0x3d0\n[ 3487.363676]  cm_work_handler+0x8a0e/0xd000\n[ 3487.367496]  process_scheduled_works+0xa07/0x13a0\n[ 3487.367859]  worker_thread+0x7c9/0xc80\n[ 3487.368148]  kthread+0x341/0x430\n[ 3487.368407]  ret_from_fork+0x3a8/0x7a0\n[ 3487.368704]  ret_from_fork_asm+0x1a/0x30\n[ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2)\n[ 3487.372840] ------------[ cut here ]------------\n[ 3487.373195] WARNING: mm/slub.c:1244 at __slab_err+0x1a/0x30, CPU#6: kworker/6:84/22254\n[ 3487.373759] Modules linked in:\n[ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G    B               7.1.0-next-20260623+ #88 PREEMPT(lazy)\n[ 3487.374778] Tainted: [B]=BAD_PAGE\n[ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n[ 3487.378515] Workqueue: ib_cm cm_work_handler\n[ 3487.378820] RIP: 0010:__slab_err+0x1a/0x30\n[ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 \u003c0f\u003e 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00\n[ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093\n[ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80\n[ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080\n[ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410\n[ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210\n[ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300\n[ 3487.388932] FS:  0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000\n[ 3487.389529] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0\n[ 3487.390440] PKRU: 55555554\n[ 3487.390641] Call Trace:\n[ 3487.390826]  \u003cTASK\u003e\n[ 3\n---truncated---",
  "id": "GHSA-pqj5-pgr6-pmv4",
  "modified": "2026-09-18T18:31:27Z",
  "published": "2026-09-17T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90172"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/383a9480f5f40bc46454cce27ccfad532cedad9c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/959813a3752b459ed77b0b3eaf30b9f4c6204260"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.