CVE-2026-46043

What it actually does

This flaw affects the Linux kernel RDMA RXE, or Soft-RoCE, receive path. A malformed RDMA/RoCE packet can provide a short payload with an attacker-controlled Base Transport Header pad value, causing payload length calculation in rxe_rcv() to underflow before the packet length is fully validated. Downstream receive-path code may then operate on an incorrect, very large payload size, creating risk of out-of-bounds memory access, kernel memory disclosure, and kernel crash or denial of service. The issue is remotely reachable when RXE/RDMA networking is exposed and does not require authentication or user interaction.

Why it matters to the business

Systems using Linux Soft-RoCE/RDMA can be crashed or potentially have sensitive kernel memory exposed by malformed network traffic. For organizations running RDMA-enabled storage, HPC, virtualization, or low-latency application infrastructure, exploitation could interrupt workloads, degrade clustered services, or expose confidential data. Although EPSS is currently low, the CVSS severity is critical and the bug is in the kernel network path, so exposed RXE deployments should be prioritized even though it is not currently listed in CISA KEV and no ransomware use is reported.

How an attack unfolds

An attacker first identifies a host with Linux RXE/Soft-RoCE enabled and reachable over the network, commonly through RoCEv2 traffic. The attacker crafts an RDMA packet that is long enough to satisfy the fixed-header length check but too short for the full expected payload once the BTH pad field and ICRC length are subtracted. By setting a forged non-zero BTH pad value, the attacker causes payload_size() to underflow. The resulting incorrect length can be passed into later RXE receive-path processing, potentially causing an out-of-bounds read, kernel fault, or system crash. Practical impact depends on kernel version, configuration, and reachable RDMA exposure; the public description supports confidentiality and availability impact, not a confirmed remote code execution primitive.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the RDMA/rxe fix titled "Validate pad and ICRC before payload_size() in rxe_rcv". No exact fixed package versions were provided in the input, so use vendor advisories for the deployed distribution and kernel stream. If RXE/Soft-RoCE is not required, disable it as a compensating control by unloading or preventing loading of the rdma_rxe module and removing unused RDMA configuration. Restrict RDMA/RoCE traffic to trusted hosts and isolated networks; block or tightly filter RoCEv2/UDP 4791 and other RDMA transport exposure at network boundaries where operationally feasible. Reboot into the patched kernel after updating, because kernel package installation alone may not activate the fix.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a build containing the RXE receive-path validation fix. Verify whether RXE is enabled by checking loaded modules and RDMA devices, for example whether rdma_rxe is loaded or RXE devices are present. Review vendor changelogs or kernel source for the added validation that checks pkt->paylen against header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE before payload_size() is used. Confirm network controls prevent untrusted access to RDMA/RoCE services, especially UDP 4791 where RoCEv2 is used. In a controlled lab only, negative-test malformed short RXE/RoCE packets and verify the patched host drops them without kernel warnings, oops, panic, or RDMA service disruption.

Typical attack path

1. Identify Linux hosts with RDMA RXE/Soft-RoCE enabled and network-reachable RDMA/RoCE traffic paths.
2. Send crafted RoCE/RDMA packets that include valid-enough fixed headers but an insufficient total packet length.
3. Set the BTH pad field so that subtracting pad bytes and the ICRC size causes payload_size() to underflow.
4. Trigger RXE receive-path code to process the malformed packet using the underflowed payload length.
5. Cause kernel memory access outside the intended packet buffer, resulting in possible information disclosure, kernel oops, panic, or service disruption.

How to detect it

Look for evidence of exploitation or probing on Linux hosts with RXE/Soft-RoCE enabled. Relevant sources include kernel logs, system journal, crash dumps, kdump/vmcore artifacts, RDMA subsystem logs, network telemetry, firewall logs, and packet captures from RDMA networks. Search for kernel oops, panic, slab or bounds-check failures, general protection faults, or call traces involving rxe_rcv, RDMA/rxe, rdma_rxe, or RXE receive processing. Correlate crashes or reboots with inbound RoCE/RDMA traffic, especially malformed or unusually short UDP/4791 packets with non-zero BTH pad fields. Network detection should focus on RoCEv2 packets whose observed packet length is shorter than the minimum implied by the headers, BTH pad value, and ICRC. Absence of logs does not rule out exploitation if the host panicked before logs were flushed; preserve crash dumps and packet captures where available.

• rdma_rxe
• rxe_rcv
• RDMA/rxe
• Soft-RoCE
• Call Trace:.*rxe_rcv
• BUG: kernel NULL pointer dereference.*rxe_rcv
• general protection fault.*rxe_rcv
• kernel panic.*rxe_rcv
• Oops:.*rxe_rcv
• UDP/4791
• RoCEv2 packet with non-zero BTH pad and length shorter than header + pad + ICRC

What your security team should do

• Inventory Linux systems using RDMA, RXE, Soft-RoCE, or the rdma_rxe kernel module, prioritizing internet-facing, cross-tenant, storage, HPC, and virtualization infrastructure.
• Patch affected systems with vendor kernels containing the RDMA/rxe payload length validation fix and reboot into the patched kernel.
• Disable rdma_rxe where Soft-RoCE is not operationally required.
• Restrict RDMA/RoCE traffic to trusted management or workload networks; block UDP 4791 from untrusted sources where RoCEv2 is not explicitly needed.
• Increase monitoring for kernel oops, panic, soft lockup, RDMA RXE errors, and unexplained reboots on RDMA-enabled Linux hosts.
• Because the issue is 76 days old with low current EPSS and no KEV listing, prioritize based on actual RXE exposure rather than broad Linux presence alone, but treat reachable RXE deployments as high urgency due to kernel-level impact.