CVE-2026-92512: RDMA/core: Fix use after free in ib_query_qp()
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix use after free in ibqueryqp()
When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdmarestrackget(), meanwhile during the QP destroy path rdmarestrackdel() is called at the end of the ibdestroyqpuser() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdmarestrackdel() is called this QP can still be accessed, which could cause the use after free below.
Fix this by moving the rdmarestrackbegindel() to the start of the ibdestroyqpuser(), 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:ibqueryqp+0x15/0x50 [ibcore] 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> mlx5ibgsiqueryqp+0x21/0x50 [mlx5ib] mlx5ibqueryqp+0x689/0x9d0 [mlx5ib] ibqueryqp+0x35/0x50 [ibcore] fillresqpentryquery.isra.0+0x47/0x280 [ibcore] ? wakeup+0x40/0x50 ? netlinkbroadcastfiltered+0x15a/0x550 ? kobjectueventenv+0x562/0x710 ? eppollcallback+0x242/0x270 ? nlaput+0xc/0x20 ? nlaput+0x28/0x40 ? nlaputstring+0x2e/0x40 [ibcore] fillresqpentry+0x138/0x190 [ibcore] resgetcommondumpit+0x4a5/0x800 [ibcore] ? fillresqpentryquery.isra.0+0x280/0x280 [ibcore] nldevresgetqpdumpit+0x1e/0x30 [ibcore] netlinkdump+0x16f/0x450 netlinkdumpstart+0x1ce/0x2e0 rdmanlrcvmsg+0x1d3/0x330 [ibcore] ? nldevresgetqprawdumpit+0x30/0x30 [ibcore] rdmanlrcvskb.constprop.0.isra.0+0x108/0x180 [ibcore] rdmanlrcv+0x12/0x20 [ibcore] netlinkunicast+0x255/0x380 ? allocskb+0xfa/0x1e0 netlinksendmsg+0x1f3/0x420 socksendmsg+0x38/0x60 syssendmsg+0x1e8/0x230 ? copymsghdrfromuser+0xea/0x170 syssendmsg+0x7c/0xb0 ? futexwait+0x95/0xf0 ? futexwakemark+0x40/0x40 ? futexwait+0x67/0x100 ? futexwake+0xac/0x1b0 syssendmsg+0x5f/0xb0 dosyscall64+0x55/0xb90 entrySYSCALL64afterhwframe+0x4b/0x53
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected path involves RDMA queue pairs (QPs) queried through the netlink flow. Exposure requires a system using RDMA and a QP that can be queried while it is being destroyed.
What race condition causes the use-after-free?
A netlink query obtains synchronization through rdma_restrack_get(), but the original destroy path did not remove the QP from resource tracking until after vendor-specific QP resources had already been destroyed. This allowed ib_query_qp() to access the QP during that interval.
How does the fix prevent the issue?
The fix moves rdma_restrack_begin_del() to the start of ib_destroy_qp_user(). This waits for active QP users to finish and removes the QP from the tracking database before destruction proceeds, preventing new access during teardown.
Is there an indicator that this issue may have occurred?
The provided failure report shows a fault in ib_query_qp() in the ib_core module during the affected access. A kernel crash report or stack trace identifying ib_query_qp() may indicate the vulnerable race was encountered.