Linux kernel - RDMA/rxe (Soft-RoCE) ICRC processing, drivers/infiniband/sw/rxe: The follow-up to CVE-2026-46043, and

CVSS 7.5CVE-2026-46133Firmware, BMC & network fabricRDMA/rxe unknown opcode ICRC out-of-boundsSoft-RoCE rxe_opcode table gapcurated

Impact

The follow-up to CVE-2026-46043, and the reason to check you have both. The rxe_opcode[] table has 256 entries but only defined IB opcodes are populated; an undefined opcode such as 0xff reads a zero-initialised entry, so the length check added by the previous fix degenerates to a comparison against zero and stops constraining the packet length. rxe_icrc_hdr() then computes length minus the BTH size, which underflows, producing an out-of-bounds read. One unauthenticated UDP packet still panics the node. The defect predates the earlier fix and reaches back to the original Soft-RoCE driver, so any kernel with rxe loaded has carried it for years.

Who can reach it

A single UDP datagram to port 4791 carrying an opcode not defined in the IB specification. No connection state, no authentication, no prior contact with the target. Trivially scriptable and trivially fleet-wide.

What to do

Host reboot / kernel upgrade to a kernel carrying this fix specifically - patching only CVE-2026-46043 leaves you exposed. As with the rest of the rxe family, the zero-cost control is to blacklist and unload rdma_rxe where Soft-RoCE is not in use (config change, no downtime), which is the right answer on essentially every production GPU node with real RDMA hardware. Where rxe must stay, restrict UDP/4791 at the host firewall and switch ACLs to known peers while the kernel rollout proceeds.

References

https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-46133.json https://nvd.nist.gov/vuln/detail/CVE-2026-46133

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.