CVE-2026-80864: RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix responder UAF on IBQPMAXDESTRDATOMIC modifyqp
rxeqpfromattr() handles IBQPMAXDESTRDATOMIC outside the IBQPSTATE path, so it holds no statelock and runs while the responder task rxereceiver() (recvtask on rxewq) is live. A modifyqp() setting only that attribute calls freerdatomicresources() then allocrdatomicresources(), swapping qp->resp.resources[] while rxeprepareres()/findresource() walk it; freerdatomicresources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxereceiver() (local DoS).
Drain recvtask around the swap with rxedisabletask()/rxeenabletask(), as rxeqpreset() already does when tearing this array down, re-enabling only after allocrdatomicresources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in freerdatomicresources(), like the rxeresp.c completion paths.
Reproduced under KASAN; the slab-use-after-free in rxereceiver() is gone.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.1.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.108 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.49 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.1.13 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.3 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In free_rd_atomic_resources(), clear the cached qp->resp.res pointer, matching the rxe_resp.c completion paths.
- Compensating control
Around the free/allocate swap of qp->resp.resources[] for IB_QP_MAX_DEST_RD_ATOMIC modify_qp, drain recv_task with rxe_disable_task(), call alloc_rd_atomic_resources(), and call rxe_enable_task() only after allocation succeeds so the responder cannot run against a NULL resource array on ENOMEM.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using the Linux kernel's RDMA RXE software transport are exposed when an unprivileged local user can modify a queue pair while its responder task is active. The described impact is local denial of service.
What does an attacker need to do to trigger the race?
The attacker needs local unprivileged access and must race a modify_qp() operation that changes only IB_QP_MAX_DEST_RD_ATOMIC against the live rxe_receiver() responder task. The race occurs while RD atomic resources are freed and reallocated.
What changed in the fix?
The fix disables and drains recv_task before replacing the responder resource array, then re-enables it only after allocation succeeds. It also clears the cached qp->resp.res pointer when RD atomic resources are freed, preventing it from remaining dangling.