GPU VulnDB

Database/Firmware, BMC & network fabric

Linux RDMA/rxe: QP error state re-executes the current packet, duplicating completions then NULL-derefing

CVSS 8.2CVE-2026-93107Firmware, BMC & network fabriccurated

Impact

If a queue pair enters the error state while a packet is being completed - an rdma_cm disconnect racing receive processing is the cited case - the rxe responder loops back into request processing with the already-completed packet. It copies the same payload once per posted receive WQE and posts a fresh IB_WC_SUCCESS completion each time (about a thousand duplicates were observed on one SEND), then dereferences a NULL WQE and panics the kernel. The duplicate completions are indistinguishable from real receives to the upper layer, so any protocol relying on RC exactly-once delivery sees silently corrupted data before the crash - an rds stress test delivered the same datagram hundreds of times. This is the software RoCE driver, not the hardware mlx5 path, so it matters on nodes that use rxe for RDMA over ordinary NICs or for test and CI fabric rather than on ConnectX-attached production fabric.

Who can reach it

Network (AV:N, PR:N per the record): a peer that can open and then abruptly disconnect an RDMA connection against an rxe device. Exposure is limited to hosts with the rxe driver loaded and a soft-RoCE device configured.

What to do

Take the stable-kernel fix (five stable commits listed) and reboot the affected hosts. If no workload needs soft-RoCE, the cheaper mitigation is to not load rxe at all - hosts using hardware RDMA via mlx5 or equivalent do not need it. Reachability is a function of whether an rxe device exists, so audit that before scheduling a fleet-wide reboot.

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.