Integer Underflow Affecting kernel-rt-64k-devel-matched package, versions *


Severity

Recommended
medium

Based on CentOS security rating.

Threat Intelligence

EPSS
0.07% (23rd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS9-KERNELRT64KDEVELMATCHED-17062407
  • published29 May 2026
  • disclosed28 May 2026

Introduced: 28 May 2026

NewCVE-2026-46133  (opens in a new tab)
CWE-191  (opens in a new tab)

How to fix?

There is no fixed version for Centos:9 kernel-rt-64k-devel-matched.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-devel-matched package and not the kernel-rt-64k-devel-matched package as distributed by Centos. See How to fix? for Centos:9 relevant fixed versions and status.

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 Base Scores

version 3.1