CVE-2026-46133
Received Received - Intake
RDMA/rxe: Out-of-Bounds Read via Unknown Opcode

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and "rdma link add"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
CVE-2026-46133
EUVD
EUVD-2026-32760
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 7.0-rc7
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's RDMA/rxe driver. It occurs because the driver does not properly reject packets with unknown opcodes before processing their integrity check (ICRC). Specifically, when a UDP packet with an unknown opcode is received, the code attempts to read data based on an array entry that is zero-initialized, causing an underflow and an out-of-bounds read of memory.

This flaw allows a single unauthenticated UDP packet to trigger a kernel panic by causing a slab-out-of-bounds read, which can lead to a system crash. The vulnerability arises because the check for packet length does not sufficiently constrain packets with unknown opcodes, allowing invalid memory access during CRC computation.

The fix involves rejecting packets with unknown opcodes before performing any length arithmetic or integrity checks.


How can this vulnerability impact me? :

This vulnerability can impact you by allowing an attacker to send a single unauthenticated UDP packet that triggers a kernel panic, causing the system to crash.

Since the vulnerability leads to an out-of-bounds memory read and subsequent kernel panic, it can result in denial of service (DoS) conditions, disrupting normal operations and potentially causing downtime.

The attack requires only that the vulnerable module be loaded and a specific RDMA link be added, with no need for authentication or established connections, making it easier for attackers to exploit.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for kernel panic or KASAN slab-out-of-bounds errors triggered by malformed UDP packets sent to port 4791 when the RDMA RXE module is loaded.

Specifically, sending a single 48-byte UDP packet with BTH opcode=0xff and QPN=IB_MULTICAST_QPN to port 4791 can reproduce the issue if the system is vulnerable.

A command to add the RDMA RXE link for testing is:

  • rdma link add rxe0 type rxe netdev eth0

Then, sending a crafted UDP packet to port 4791 with opcode 0xff can be used to test for the vulnerability. However, no specific detection commands are provided in the available information.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by rejecting packets whose opcode has no valid rxe_opcode[] entry before any length arithmetic is performed.

Immediate mitigation steps include:

  • Apply the patch or update the Linux kernel to a version that includes the fix rejecting unknown opcodes in the RDMA RXE driver.
  • If patching is not immediately possible, consider disabling the RDMA RXE module or blocking UDP traffic to port 4791 to prevent exploitation.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart