CVE-2026-80864: RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp

Published Sep 4, 2026
·
Updated

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

1 affected component
Linux Kernel

Event History

Sep 4, 2026
CVE Published
via MITRE·03:55 PM
Data Sourced
via MITRE·03:55 PM
Description

Frequently Asked Questions

1

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.

2

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.

3

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203