CVE-2026-46114

Technical summary

The vulnerability resides in drivers/infiniband/sw/rxe/rxe_resp.c within the atomic_write_reply() function. The code unconditionally dereferences an 8-byte value from a packet payload without validating that the payload is actually 8 bytes long. An attacker can send an ATOMIC_WRITE request with RETH length set to 0, bypassing existing validation in check_rkey() that only compared packet length (pktlen) against remaining bytes (resid). This causes the responder to read 8 bytes from past the logical end of the packet into the socket buffer's head tailroom, then write those bytes via rxe_mr_do_atomic_write() into the attacker's memory region. The leaked data includes the 4-byte kernel tailroom content plus the packet's trailing ICRC. Per IBA specification oA19-28, ATOMIC_WRITE operations must be exactly 8 bytes; the fix enforces strict length validation in check_rkey() before the unsafe dereference is reached.

Business impact

This vulnerability enables remote, unauthenticated disclosure of sensitive kernel memory to an attacker with network access to a RoCE endpoint. Organizations using RDMA for high-performance computing, storage clusters, or data center interconnects face exposure of kernel addresses and data structures that could aid in further exploitation. The leakage occurs in small increments per probe, but sustained attacks can accumulate reconnaissance information. While no authentication is required and the attack is highly reliable, the impact is limited to information disclosure; system integrity and availability are not compromised.

Affected systems

The Linux kernel RoCE (RDMA over Converged Ethernet) driver is affected. This impacts systems running vulnerable kernel versions that have not applied the patch. RoCE is commonly deployed in high-performance computing clusters, data centers, and storage solutions that rely on kernel-based RDMA implementations. The vulnerability applies to the software RXE (SoftRoCE) driver implementation in the kernel.

Exploitability

Exploitability is very high. No authentication, credentials, or user interaction is required. An attacker needs only network access to a system with an active RoCE endpoint. The attack is straightforward: send a crafted ATOMIC_WRITE request with zero payload length. The vulnerability is deterministic and repeatable, allowing reliable information leakage. However, as this is not yet in the CISA Known Exploited Vulnerabilities catalog, public exploit code may not be readily available, though the vulnerability is straightforward to weaponize given the clear root cause and reproducibility noted in the advisory.

Remediation

Apply the kernel patch that implements strict 8-byte length validation for ATOMIC_WRITE operations in check_rkey() before the unsafe dereference occurs. Verify the patch against official Linux kernel repositories or your distribution's security advisories to obtain the correct version number. Until patched, network segmentation to limit access to RoCE endpoints from untrusted sources may reduce exposure, though this is not a complete mitigation. Organizations should prioritize this patching given the ease of exploitation.

Patch guidance

Obtain and apply the upstream Linux kernel fix from the official Linux repository. The patch adds mandatory length validation for ATOMIC_WRITE payloads, rejecting any request that is not exactly 8 bytes. Coordinate patching through your standard kernel update process. Test the patched kernel in a controlled environment before deployment to production clusters. Verify that RoCE functionality remains operational post-patch. Distributions should release security updates shortly after the upstream fix; monitor your Linux vendor's security advisory channels (Red Hat, Ubuntu, SUSE, etc.) for specific patch versions applicable to your deployment.

Detection guidance

Monitor network traffic for ATOMIC_WRITE RDMA requests with zero or non-8-byte payloads. Intrusion detection systems with RDMA protocol awareness can flag such packets. On the kernel side, enable audit logging for RDMA operations if available in your kernel configuration. Look for ICRC errors or protocol violations logged by the RXE driver. Correlate with suspicious memory access patterns on systems hosting RoCE endpoints. Note that the vulnerability leaves no obvious local trace on the victim system; detection relies primarily on observing the malicious network traffic or the attacker's memory region receiving unexpected data.

Why prioritize this

Despite not being on CISA's KEV list, this should be prioritized for patching due to the CVSS 7.5 score (HIGH severity), complete lack of authentication or user interaction requirements, and straightforward exploitability. The vulnerability enables reliable remote information disclosure from the kernel, which is typically a precursor to further exploitation. Any organization running RoCE infrastructure should treat this as high priority. Patch timelines should align with your organization's critical infrastructure update policies, with urgency proportional to the sensitivity of data in affected systems and the exposure to untrusted networks.

Risk score, explained

CVSS 3.1 score of 7.5 reflects HIGH severity. Attack vector is Network (AV:N), attack complexity is Low (AC:L), no privileges required (PR:N), and no user interaction needed (UI:N). The scope is Unchanged (S:U), indicating impact is limited to the vulnerable component. Confidentiality impact is High (C:H) due to kernel memory leakage, but Integrity and Availability are None (I:N, A:N) since the attacker cannot modify data or crash the system through this path. The score accurately represents a dangerous information disclosure vulnerability with trivial exploitation.

Frequently asked questions