Status: UPDATED | Advisory ID: CVE-2026-92525
| CVE | CVE-2026-92525 |
| CVSS Score / Version | |
| Updated | 2026-10-19 |
| CVSS Vector | |
| CVSS Prose | |
| Affected products |
| Vendor | Product | Affected Versions | Patch Status |
|---|---|---|---|
| Linux | Linux Kernel |
| Subsystems | OT Supporting Infrastructure |
| Sectors | All Sectors |
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. (NVD)
Monitor Linux's web page for any future patch releases.
| Source | Reference |
|---|---|
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-92525 |
| CVE | https://www.cve.org/CVERecord?id=CVE-2026-92525 |