CVE-2026-92525

High · 7.1

CVSS

7.1

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's built-in RDMA networking code allows any local user to crash the machine or peek at internal memory.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Low
Impact: Denial Of Service
Component: OS kernel
Class: Memory Corruption
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

Out-of-bounds read in RDMA/rxe copy_data() when an attacker-controlled cur_sge or oversized num_sge indexes wqe->dma.sge[] for user QPs whose WQEs bypass validation in rxe_post_send().

Why it matters to the business

Local denial-of-service or limited information disclosure on systems using soft RDMA (rxe), potentially disrupting availability of RDMA-dependent workloads or exposing kernel memory contents.

How an attack unfolds

A local unprivileged attacker opens a user QP, posts a send WQE with out-of-range num_sge/cur_sge directly into the ring buffer, and lets rxe_requester() consume it via req_next_wqe() and copy_data() without the bounds that validate_send_wr() applies only to kernel paths.

How to fix it

Apply the upstream fix that adds bounds checking of num_sge against qp->sq.max_sge and cur_sge only when dma.resid indicates payload in rxe_requester(), then rebuild and reboot onto the patched kernel.

How to confirm the fix worked

Inspect the rxe_requester() and copy_data() paths in the running kernel source or binary to confirm the max_sge guard and early return for zero-length copies are present; re-test with KASAN enabled using a reproducer that previously triggered the OOB read.

Typical attack path

Obtain local unprivileged shell on the target host
Open an RDMA user QP via the rxe driver
Post a send work request containing num_sge or cur_sge outside the valid range
Trigger send_task processing so rxe_requester calls copy_data on the malformed WQE
Observe kernel oops or KASAN report from the vmalloc out-of-bounds read

How to detect it

Search kernel logs, dmesg, or journalctl for KASAN or BUG reports referencing copy_data, rxe_requester, or dma.sge indexing; correlate with processes using RDMA verbs immediately prior to the fault.

What your security team should do

Prioritize kernel updates on any host exposing RDMA/rxe interfaces
Limit unprivileged access to RDMA devices via permissions or cgroups where feasible
Enable kernel hardening features such as KASAN in test environments to surface similar issues
Review logs for unexpected RDMA QP errors or memory faults after patching

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone.

Affected packages

Ecosystem	Package	Introduced	Fixed