Look up another CVE · open CVE-2026-90308 in the interactive tracker
CVE-2026-90308
RDMA/erdma: Hold QP references for AE and CM processing
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/infiniband. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-90308 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| 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
AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users.
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/hw/erdma/erdma_cm.c
drivers/infiniband/hw/erdma/erdma_eq.c
drivers/infiniband/hw/erdma/erdma_verbs.c
drivers/infiniband/hw/erdma/erdma_verbs.h
- What this is
- ALIBABA ELASTIC RDMA DRIVERMAINTAINERS section matched on drivers/infiniband/hw/erdma · linux-rdma@vger.kernel.org · Supported
- Kernel module
- none to look for. The file would have gone into erdma, and Debian does not compile it into that module, so finding erdma in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_INFINIBAND|CONFIG_INFINIBAND_ERDMA' /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.
Show whether Debian builds this, per release
Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_INFINIBAND, CONFIG_INFINIBAND_ERDMA
- 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.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 5.2% 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 |
|---|---|---|
| 6.0 | 6.12.110 | 6e32f84b63c0 |
| 6.0 | 6.18.52 | ec987c065465 |
| 6.0 | 7.2.6 | c92686867638 |
| 6.0 | 7.3 | a52eeff32024 |
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:LAttack vector, local
- The UAF is a race between local ib_uverbs_destroy_qp()->erdma_destroy_qp() dropping the QP kref and either ucma_connect()/ucma_accept() (RDMA_USER_CM_CONNECT/ACCEPT -> iw_cm_connect()/iw_cm_accept() -> erdma_connect()/erdma_accept() xa_load of userspace params->qpn) or erdma_comm_irq_handler()->erdma_aeq_event_handler(). The CM QPN is rdma_ucm_conn_param.qp_num, not a remote iWARP/RoCE field.
- AC:LAttack complexity, low
- The attacker who created the QP drives both sides: one thread issues ucma_connect()/ucma_accept() or QP ops that produce an AEQE, while another calls ib_uverbs_destroy_qp(), racing find_qp_by_qpn()/xa_load against the destroy-path erdma_qp_put(). The window (bare xa_load, then kref_get or no get at all) can be retried across many QPs.
- PR:LPrivileges required, low
- ib_uverbs_open() and ucma_open() perform no capability check; uverbs_devnode() and ucma_misc.mode publish /dev/infiniband/uverbs* and /dev/infiniband/rdma_cm as 0666, so an unprivileged user on an ERDMA host can create_qp, RDMA_USER_CM_CONNECT/ACCEPT, and destroy_qp.
- UI:NUser interaction, none
- The attacker creates the QP via uverbs, issues ucma_connect()/ucma_accept() (or generates an AEQE) and ib_uverbs_destroy_qp() from their own processes; no other user must mount, open, or otherwise act.
- S:UScope, unchanged
- The use-after-free is of the host kernel's struct erdma_qp (kref, ibqp.event_handler, queue buffers) under the same kernel authority and does not cross a VM, IOMMU, or guest-host boundary.
- C:HConfidentiality impact, high
- After erdma_destroy_qp() drops the last kref and the RDMA core frees the QP, erdma_aeq_event_handler() still reads qp->ibqp.event_handler and qp_context from the freed object, and erdma_connect() may kref_get a freed QP; a sprayed replacement yields a kernel-memory read primitive.
- I:HIntegrity impact, high
- erdma_aeq_event_handler() invokes qp->ibqp.event_handler on the freed erdma_qp, and erdma_connect()/erdma_accept() write qp->cep and take qp->state_lock after a lockless xa_load; reclaiming that object gives a function-pointer call and kernel writes.
- A:HAvailability impact, high
- Using the QP after erdma_qp_put()/wait_for_completion() has released its queues and the ib_qp object causes a kernel oops or panic in erdma_aeq_event_handler() or in erdma_connect()/erdma_accept().