PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-46114 Linux CVE debrief

A remote information disclosure vulnerability exists in the Linux kernel's RDMA/rxe (Soft-RoCE) driver. The `atomic_write_reply()` function in `drivers/infiniband/sw/rxe/rxe_resp.c` unconditionally dereferences 8 bytes from the packet payload without validating that the payload contains exactly 8 bytes as required by the InfiniBand Architecture specification (IBA oA19-28). The `check_rkey()` function previously accepted ATOMIC_WRITE requests with `pktlen == resid == 0`, allowing a remote initiator to send a zero-length ATOMIC_WRITE request. This causes the responder to read 8 bytes from beyond the logical end of the packet—specifically from skb head-buffer tailroom—and write those bytes into the attacker's Memory Region via `rxe_mr_do_atomic_write()`. This results in remote disclosure of kernel memory contents, including recognizable kernel strings and partial kernel-direct-map pointer words. The vulnerability was reproduced on mainline kernels with sustained zero-length ATOMIC_WRITE probes. The fix enforces strict 8-byte payload validation in `check_rkey()` before reaching the vulnerable dereference, while preserving existing WRITE-family length logic for normal RDMA WRITE operations.

Vendor
Linux
Product
Unknown
CVSS
HIGH 7.5
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-28
Original CVE updated
2026-05-30
Advisory published
2026-05-28
Advisory updated
2026-05-30

Who should care

Organizations running Linux kernels with Soft-RoCE (rxe) enabled, particularly those exposing RDMA services to untrusted networks or multi-tenant environments. Cloud providers, HPC facilities, and storage systems using RDMA over converged Ethernet (RoCE) software implementations.

Technical summary

The RDMA/rxe (Soft-RoCE) driver implements the InfiniBand ATOMIC_WRITE operation without proper payload length validation. The `check_rkey()` function only compared `pktlen` against `resid`, accepting requests where both were zero. This allowed remote attackers to trigger an 8-byte out-of-bounds read from skb tailroom in `atomic_write_reply()`, leaking kernel memory into attacker-controlled Memory Regions. The fix adds explicit 8-byte payload validation to `check_rkey()` before the ATOMIC_WRITE path reaches `atomic_write_reply()`.

Defensive priority

high

Recommended defensive actions

  • Apply the relevant stable kernel patch for your kernel version: 5.10.y (ref-4), 5.15.y (ref-5), 6.1.y (ref-6), 6.6.y (ref-7), or 6.12.y (ref-8)
  • If Soft-RoCE (rxe) is not required, consider disabling or blacklisting the rxe kernel module as a temporary mitigation
  • Monitor for suspicious RDMA traffic patterns involving ATOMIC_WRITE operations with anomalous length fields
  • Review RDMA fabric access controls to restrict initiator connections to trusted endpoints
  • Audit kernel logs for rxe responder errors that may indicate probing activity

Evidence notes

The vulnerability description provides detailed technical analysis including the vulnerable code path (`atomic_write_reply()` → `*(u64 *)payload_addr(pkt)`), the insufficient validation in `check_rkey()`, and reproduction results confirming kernel memory disclosure. Five stable kernel patches are referenced. The IBA oA19-28 specification is cited as the protocol authority defining ATOMIC_WRITE as exactly 8 bytes.

Official resources

The vulnerability was disclosed via the Linux kernel stable tree with patches committed on 2026-05-28. The issue was identified through code review and reproduction testing that confirmed kernel memory leakage. No known exploitation in thew