Linux kernel rdma_rxe: use-after-free in the responder task when modify_qp swaps the RD-atomic resource array

Impact

rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the state-change path, so it frees and reallocates qp->resp.resources[] while the responder task rxe_receiver() is still running and walking that array, and free_rd_atomic_resources() leaves the cached qp->resp.res pointer dangling. A local unprivileged user with access to the RDMA device can race a modify_qp() call against live receive traffic and land a slab use-after-free, reproduced under KASAN. The realistic outcome is a kernel crash and the loss of the node, not a demonstrated privilege escalation, but on a GPU node any oops means an unscheduled reboot and the eviction of every job resident on the box. This only bites hosts that load the software RoCE driver rdma_rxe; fleets that run RDMA exclusively on ConnectX or other hardware HCAs are not exposed unless rdma_rxe is also present.

Who can reach it

Local unprivileged user who can open an RDMA device and issue modify_qp on a queue pair backed by rdma_rxe. No special capability is needed beyond access to the uverbs character device, which container tenants often have when RDMA is passed into pods.

What to do

Take the fix from the stable trees listed in the record, which drains recv_task with rxe_disable_task()/rxe_enable_task() around the swap and clears qp->resp.res on free. No fixed release number is stated in the record beyond the commit ids. Applying it means a kernel update and a reboot of each node; as an interim measure, hosts that do not need software RoCE can blacklist or unload the rdma_rxe module, which removes the exposure without a reboot.

References

Related entries

• Linux kernel mlx5_ib: implicit ODP parent mkey re-registered in place, racing its child mkeys and mr->pdCVE-2026-80880 · Linux kernel mlx5_ib implicit ODP (rereg_mr on a parent mkey)Unscored
• ASPEED BMC (host-to-BMC bridges generally): The ASPEED LPC/PCIe bridge architecture exists to let the host talkNCVD-0000-001-aspeed-bmc-host-to-bmc-bridges-g · ASPEED BMC (host-to-BMC bridges generally)Unscored
• IPMI over LAN as a protocol: IPMI has no transport confidentiality guarantees worth relying on, weak session handlingNCVD-0000-002-ipmi-over-lan-as-a-protocol · IPMI over LAN as a protocolUnscored
• Internet-exposed BMC: Shodan-visible BMCs are a recurring finding at colo/neocloud buildoutsNCVD-0000-003-internet-exposed-bmc · Internet-exposed BMCUnscored
• InfiniBand subnet manager (OpenSM / UFM): The IB subnet manager has unilateral authority over LID assignment, routingNCVD-0000-004-infiniband-subnet-manager-opensm · InfiniBand subnet manager (OpenSM / UFM)Unscored
• RDMA / RoCE: RoCE and IB RDMA have no cryptographic authentication of the QP connection setup or of subsequentNCVD-0000-005-rdma-roce · RDMA / RoCEUnscored