Look up another CVE · open CVE-2026-93107 in the interactive tracker
CVE-2026-93107
RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/infiniband. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-93107 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| 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
When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+0xf36/0x1dd0 The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected. A live packet reaching the error-state check in do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case.
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_resp.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
- 8.2 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.54%, higher than 44.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.4 | 6.6.157 | c319b986a88c |
| 6.4 | 6.12.110 | 62a4b48767e0 |
| 6.4 | 6.18.52 | 399713f1f0ea |
| 6.4 | 7.2.6 | 0d37e2503efd |
| 6.4 | 7.3 | 15ae32c4a355 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| 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:NAttack vector, network
- The reprocessed bytes are a RoCEv2 RC SEND (IB_OPCODE_RC_SEND_ONLY/LAST) received on UDP 4791 in rxe_udp_encap_recv()→rxe_rcv()→rxe_resp_queue_pkt(); the same peer puts the QP in ERR during do_complete() via a CM DREQ (rdma_disconnect→cma_modify_qp_err) or an AETH NAK in rxe_completer().
- AC:LAttack complexity, low
- The race is do_complete() in rxe_receiver() (rxe_wq recv_task) versus a concurrent rxe_qp_error()/rxe_qp_from_attr() setting IB_QPS_ERR; the attacker sends both the SEND and the DREQ/NAK, so they control both sides and can retry until the window is hit.
- PR:NPrivileges required, none
- hdr_check() only binds the SEND to an established RC QP (BTH QPN, check_addr() on the QP AV, default PKey); that is the RoCE connection handshake, not a local uid or capability, so the remote peer needs no OS privileges.
- UI:NUser interaction, none
- Once the SEND is queued, rxe_receiver() runs from rxe_wq by itself; no local user action is required to process the packet or to handle the peer's DREQ/NAK.
- S:UScope, unchanged
- Duplicate IB_WC_SUCCESS completions and the copy_data() oops occur inside the host rxe responder; they do not cross a VM, IOMMU, or sandbox boundary.
- C:NConfidentiality impact, none
- The crash is a NULL load of qp->resp.wqe->dma.resid in copy_data() (address 0x14) after the RQ is empty; earlier send_data_in() copies only replay the attacker's own SEND payload into posted recv MRs and do not disclose kernel memory.
- I:LIntegrity impact, low
- When do_complete() returns RESPST_CHK_RESOURCE, execute()/send_data_in() copies that same SEND into every remaining recv WQE and do_complete() posts another IB_WC_SUCCESS (qp->resp.status still 0), breaking RC exactly-once delivery for this QP's posted RQ; that is not an arbitrary kernel write.
- A:HAvailability impact, high
- After the RQ is exhausted, send_data_in() calls copy_data() with qp->resp.wqe == NULL and oopses on rxe_wq (RIP copy_data), as in the reported NULL-pointer dereference.