Linux kernel - RDMA/rxe (Soft-RoCE) responder, drivers/infiniband/sw/rxe/rxe_resp.c: Atomic_write_reply() dereferences

CVSS 7.5CVE-2026-46114Firmware, BMC & network fabricRDMA/rxe ATOMIC_WRITE zero-length disclosureSoft-RoCE skb tailroom leakcurated

Impact

Atomic_write_reply() dereferences 8 bytes at the payload address unconditionally, while the rkey check accepted an ATOMIC_WRITE with a RETH length of zero. A remote initiator sending a zero-length ATOMIC_WRITE makes the responder read 8 bytes past the logical end of the packet into the socket buffer's tailroom and then write those bytes into the attacker's own memory region. That is a clean remote read primitive: four bytes of uninitialised kernel memory disclosed to the attacker per probe, repeatable at will, ideal for defeating KASLR or harvesting kernel pointers before a heavier exploit. The IB specification defines ATOMIC_WRITE as exactly 8 bytes, so anything else was always protocol-invalid.

Who can reach it

Remote initiator on an rxe connection sets the RETH length to 0 on an ATOMIC_WRITE and reads back the responder's reply, which now contains kernel tailroom bytes. Repeat to accumulate a memory-disclosure oracle. No local privilege and no authentication beyond reaching the Soft-RoCE endpoint.

What to do

Host reboot / kernel upgrade. Same family control as the other rxe findings: blacklist and unload rdma_rxe where Soft-RoCE is not intentionally deployed, which is a config change with no downtime and removes this along with the rest. Where rxe is in use, upgrade the kernel and reboot on rolling drain, and firewall UDP/4791 to known peers in the meantime.

References

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

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.