Look up another CVE · open CVE-2026-92525 in the interactive tracker
CVE-2026-92525
RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/infiniband. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-92525 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/infiniband/sw/rxe/rxe_req.c
- What this is
- SOFT-ROCE DRIVER (rxe)MAINTAINERS section matched on drivers/infiniband/sw/rxe/ · linux-rdma@vger.kernel.org · Supported
- Kernel module
- rdma_rxe
Check it on the machine
grep -wE 'CONFIG_INFINIBAND|CONFIG_RDMA_RXE' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w rdma_rxePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_INFINIBAND, CONFIG_RDMA_RXE
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 4.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/infiniband
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.8 | 6.1.188 | 69d3ccf6543f |
| 4.8 | 6.6.157 | 750bba6ce9bb |
| 4.8 | 6.12.110 | c067aa7b231e |
| 4.8 | 6.18.52 | 13cb7160e5b7 |
| 4.8 | 7.2.6 | 5ec111ddc1f7 |
| 4.8 | 7.3 | 126c757e4cd4 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The attacker writes dma.num_sge/dma.cur_sge into the mmap'd send queue (rxe_init_sq→vmalloc_user, rxe_mmap); ib_uverbs_post_send only doorbells rxe_post_send, which for qp->is_user skips validate_send_wr() and schedules rxe_requester(). Inbound RoCE/UDP packets do not carry these WQE index fields.
- AC:LAttack complexity, low
- The attacker fully controls the mmap'd SQ slot (cur_sge, num_sge, resid, opcode) and the producer_index, then issues IB_USER_VERBS_CMD_POST_SEND; rxe_requester→finish_packet→copy_data indexes sge[] with no race and no victim-side state.
- PR:LPrivileges required, low
- uverbs_devnode() publishes /dev/infiniband/uverbsN as 0666; ib_uverbs_open, ib_uverbs_create_qp, ib_uverbs_modify_qp and ib_uverbs_post_send require no capability for IB_QPT_UD/RC, so an unprivileged local user can create a user QP, mmap the SQ and post the malformed WQE.
- UI:NUser interaction, none
- The attacker creates their own user QP, writes the malformed send WQE into their mmap'd SQ and doorbells post_send; no other user must mount, open a file, or otherwise act.
- S:UScope, unchanged
- The vmalloc OOB in copy_data() runs in the host kernel rxe requester on behalf of the local process and does not cross a VM, guest-to-host, or IOMMU/DMA authority boundary.
- C:HConfidentiality impact, high
- copy_data() does &dma->sge[dma->cur_sge] with attacker-controlled u32 cur_sge/num_sge into the vmalloc SQ and then reads sge->length/lkey/addr; an oversized num_sge also lets the sge++ loop walk unbounded kernel vmalloc (KASAN vmalloc-out-of-bounds).
- I:NIntegrity impact, none
- finish_packet() calls copy_data(..., RXE_FROM_MR_OBJ), which only reads MR contents into the SKB; the OOB is a read of sge descriptors, dma updates stay in the attacker's mmap'd WQE, and lookup_mr/rxe_mr_copy remain confined to MRs in the caller's PD.
- A:HAvailability impact, high
- Indexing &wqe->dma.sge[cur_sge] past the vmalloc_user send-queue object is a KASAN-reproduced vmalloc-out-of-bounds in copy_data() that oopses/panics the kernel.