Linux kernel Soft-RoCE: modify_qp frees the rd_atomic array using the new size, writing out of bounds

Impact

rxe_qp_from_attr() updates qp->attr.max_dest_rd_atomic before freeing the old responder resource array, so free_rd_atomic_resources() iterates using the new, larger count and walks past the old allocation - KASAN reports a 4-byte slab out-of-bounds write reached from userspace through ib_uverbs_modify_qp. In a GPU cluster the uverbs device node is exactly what tenant pods are given when RDMA is exposed for NCCL, so the trigger is an ordinary queue-pair modify from an unprivileged process. This affects the Soft-RoCE software driver only; nodes using ConnectX/mlx5 hardware verbs without rdma_rxe loaded are not affected. A controlled slab out-of-bounds write is a memory-corruption primitive, but the record establishes only the KASAN crash, not working escalation.

Who can reach it

Local unprivileged user with access to an rxe RDMA device - an /dev/infiniband/uverbs* fd, which containers get when /dev/infiniband is mapped in. No authentication beyond that device access, and no path from the fabric wire.

What to do

Apply the stable kernel fix (linked commits) and reboot each affected node after draining it; the record names commits, not a fixed release. If a reboot cannot be scheduled, the exposure goes away by not loading the rdma_rxe module and not passing /dev/infiniband/uverbs* into tenant pods on Soft-RoCE hosts.

References

Related entries

• Linux kernel rdma_rxe: use-after-free in the responder task when modify_qp swaps the RD-atomic resource arrayCVE-2026-80864 · Linux kernel Soft-RoCE responder (rdma_rxe, IB_QP_MAX_DEST_RD_ATOMIC modify_qp)Unscored
• 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