GPU VulnDB

Database/Firmware, BMC & network fabric

Linux kernel RDMA/rxe: use-after-free on multicast group when rxe_mcast_add() fails

CVSS 7.0CVE-2026-98360Firmware, BMC & network fabriccurated

Impact

rxe_get_mcg() published a newly allocated multicast group in rxe->mcg_tree before programming the backing Ethernet multicast address. If rxe_mcast_add() then failed - for example -ENODEV when the backing netdev has been removed, or a propagated dev_mc_add() error - the unwind freed the group without removing it from the tree, and the next lookup of the same MGID dereferenced freed memory. The fix was validated under KASAN with the error return forced. This is the software RoCE provider, not a ConnectX or other hardware HCA, so it only matters on nodes that actually load rxe - test rigs, nodes without an RDMA-capable NIC, or containers that fall back to soft-RoCE. Where it is loaded, a local RDMA client reaches the path with ATTACH_MCAST on a UD QP, which makes a kernel-memory corruption primitive available to an unprivileged tenant process that holds an RDMA device.

Who can reach it

Local userspace RDMA client issuing ATTACH_MCAST on a UD QP against an rxe device; no elevated privilege beyond access to the RDMA device. Requires the rxe_mcast_add() error path to be reached, which the record describes as needing an error such as netdev removal. Not reachable from the network.

What to do

Apply the stable kernel commits in the record and reboot each affected node. If rxe is not required, the cheaper mitigation is to not load it: blacklist the rdma_rxe module and confirm it is absent from running nodes, which removes the exposure without a kernel update. Nodes using hardware RDMA (mlx5, irdma, bnxt_re) are unaffected by this path.

References

Related entries

All Firmware, BMC & network fabric entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.