RDMA/core: Fix use after free in ib_query_qp()

Answer in brief

CVE-2026-92512 records a Unknown severity vulnerability in RDMA/core: Fix use after free in ib_query_qp(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Sep 17, 2026Updated Sep 17, 2026Source checked Sep 17, 2026First seen by HOL Sep 17, 2026Material review Sep 17, 2026

Upstream Advisory

Key facts

Risk: Unknown severitySource severity not reported
Exploitation: Not marked as known exploited
Affected software: 2 mapped packages or products
Fix availability: Available

Why this deserves its current priority

A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=514aee660df493cd673154a6ba6bab745ec47b8c <2ef2ea52ae41bd9efa83139e97ae839de7e17156 \|\| >=514aee660df493cd673154a6ba6bab745ec47b8c <a608af8cde3dd38936b356bbdeedea0653a05b3f \|\| >=514aee660df493cd673154a6ba6bab745ec47b8c <8998829739c31fdbc892078e4449887d902e5dc9 \|\| >=514aee660df493cd673154a6ba6bab745ec47b8c <038cf231b7099ba6202dcc0c1ea01525122df09f \|\| >=514aee660df493cd673154a6ba6bab745ec47b8c <001383248e5d754bbddb7ae2a8573bc8501c85d8 \|\| >=514aee660df493cd673154a6ba6bab745ec47b8c <709ba0e5311bd034eb4d9c1c00cc4e1109d6dc3e	2ef2ea52ae41bd9efa83139e97ae839de7e17156, a608af8cde3dd38936b356bbdeedea0653a05b3f, 8998829739c31fdbc892078e4449887d902e5dc9, 038cf231b7099ba6202dcc0c1ea01525122df09f, 001383248e5d754bbddb7ae2a8573bc8501c85d8, 709ba0e5311bd034eb4d9c1c00cc4e1109d6dc3e
Linux/Linuxgeneric	5.15	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to 2ef2ea52ae41bd9efa83139e97ae839de7e17156 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Sep 17, 2026

Sources and claim methodology

Upstream source description

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix use after free in ib_query_qp() When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Quoted source text, attributed separately from HOL analysis.