CVE-2026-46114

What it actually does

This is a remote information disclosure flaw in the Linux kernel Soft-RoCE/RDMA rxe driver. The rxe responder accepted an invalid RDMA ATOMIC_WRITE request with a zero-length payload even though the protocol requires ATOMIC_WRITE payloads to be exactly 8 bytes. The vulnerable code then unconditionally read 8 bytes from the packet buffer, causing it to read past the logical end of the packet into adjacent skb tailroom. Four useful bytes of adjacent kernel memory may be disclosed per probe, while the remaining bytes may include packet trailer data such as ICRC. Repeated probing can expose kernel strings or partial kernel pointer values, potentially weakening kernel address-space randomization and supporting later exploitation.

Why it matters to the business

Organizations exposing Linux Soft-RoCE/RDMA services on reachable networks may allow an unauthenticated remote party to read small fragments of kernel memory. The direct impact is confidentiality loss rather than service disruption or data modification, but leaked kernel pointers or memory fragments can materially increase the success of follow-on attacks against the same host. The issue is not currently listed in CISA KEV, has no reported ransomware association, and has low EPSS at the time provided, but network-reachable RDMA endpoints should still be treated as sensitive infrastructure because exploitation requires only crafted protocol traffic once the service is reachable.

How an attack unfolds

An attacker first identifies a host exposing the Linux rxe Soft-RoCE RDMA stack, commonly over a RoCE/RDMA-capable network path. The attacker establishes or reaches the necessary RDMA communication context and sends a malformed ATOMIC_WRITE request whose RETH length is zero instead of the protocol-required 8 bytes. On vulnerable kernels, the request passes the earlier length validation because the packet length and residual length are both zero. The responder then enters atomic_write_reply() and dereferences an 8-byte value from payload_addr(pkt) even though the logical payload is empty. This causes the kernel to read bytes from adjacent skb buffer tailroom and write the resulting value into memory observable by the attacker through the RDMA operation. By repeating the malformed request, the attacker can sample small fragments of kernel memory, potentially including recognizable strings or partial direct-map pointer words.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the RDMA/rxe fix enforcing ATOMIC_WRITE payload length to exactly 8 bytes before atomic_write_reply() is reached. No exact fixed version was provided in the input, so use the relevant Linux distribution, appliance, or kernel vendor advisory as the source of truth. If RDMA Soft-RoCE is not required, disable or unload the rxe/rdma_rxe functionality and prevent it from loading at boot. Restrict RDMA/RoCE exposure to trusted, isolated networks only; block or tightly control RoCEv2 traffic, commonly UDP port 4791, and relevant L2 RoCE traffic where applicable. Treat RDMA-capable networks as privileged infrastructure and avoid exposing them to untrusted hosts.

How to confirm the fix worked

Confirm that the running kernel package includes the upstream fix for RDMA/rxe that rejects non-8-byte ATOMIC_WRITE payloads. Verify whether the vulnerable component is active by checking for loaded rxe/rdma_rxe modules and configured RDMA links. On systems where kernel source or build metadata is available, confirm that check_rkey() or equivalent rxe request validation rejects ATOMIC_WRITE lengths other than 8 bytes. In a controlled test environment only, send a malformed zero-length ATOMIC_WRITE probe: patched systems should reject the PDU and leave the target memory region unchanged, while vulnerable systems may copy nonzero tailroom bytes. Also validate compensating controls by confirming RDMA/RoCE traffic is blocked from untrusted segments.

Typical attack path

1. Discover Linux systems exposing RDMA/RoCE functionality, especially Soft-RoCE using the rxe driver.
2. Establish access to the RDMA service path and prepare an RDMA queue pair or equivalent protocol interaction.
3. Craft an ATOMIC_WRITE request with an invalid zero-byte RETH length.
4. Send repeated malformed ATOMIC_WRITE probes to the vulnerable responder.
5. Collect the returned or written 8-byte values in attacker-controlled or attacker-readable RDMA memory.
6. Filter leaked values for kernel strings, pointer-like values, or other useful memory fragments.
7. Use the disclosed information to support reconnaissance or subsequent kernel exploitation attempts.

How to detect it

Post-exploitation detection is difficult because the vulnerable read occurs inside kernel packet handling and may not produce application logs, authentication events, or crashes. Focus on network telemetry, RDMA subsystem visibility, and host configuration evidence. Review packet captures or RDMA-aware monitoring for malformed ATOMIC_WRITE operations with a zero RETH length, repeated ATOMIC_WRITE probes, or unusual RDMA traffic from untrusted peers. Check kernel, system, and RDMA logs for rxe, Soft-RoCE, queue pair errors, malformed request handling, or unexpected RDMA connection attempts. Examine whether rdma_rxe was loaded unexpectedly, whether new RDMA links appeared, or whether RoCE traffic was observed from systems that should not use RDMA. Because successful exploitation may leave little or no durable artifact, absence of logs should not be treated as proof of non-exploitation.

• rdma_rxe
• rxe
• Soft-RoCE
• drivers/infiniband/sw/rxe/rxe_resp.c
• atomic_write_reply
• rxe_mr_do_atomic_write
• ATOMIC_WRITE
• IB_OPCODE_RC_ATOMIC_WRITE
• RETH length 0
• reth.length=0
• UDP/4791
• RoCEv2

What your security team should do

• Prioritize patching Linux systems that run Soft-RoCE/RDMA and are reachable from any non-isolated network segment.
• Inventory hosts with loaded rxe/rdma_rxe modules or configured RDMA links and determine whether RDMA is required.
• Disable Soft-RoCE/RDMA where there is no clear business requirement.
• Restrict RoCE/RDMA traffic to trusted hosts and dedicated networks; do not permit internet or broadly routed enterprise exposure.
• Add network monitoring for malformed or unusual RDMA ATOMIC_WRITE activity, especially zero-length ATOMIC_WRITE requests where protocol visibility exists.
• Review recent RDMA-accessible systems for suspicious probing, crashes, unexpected RDMA connection attempts, or anomalous high-rate atomic operations.
• Track Linux distribution advisories for exact fixed kernel package versions and deploy vendor-supported updates rather than relying only on upstream commit presence.