Look up another CVE · open CVE-2026-93151 in the interactive tracker
CVE-2026-93151
nvmet-rdma: fix response resource leak on queue teardown
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/nvme. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-93151 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
When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm "kworker/2:1H", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm "kworker/3:1H", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.
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/nvme/target/rdma.c
- What this is
- NVM EXPRESS TARGET DRIVERMAINTAINERS section matched on drivers/nvme/target/ · linux-nvme@lists.infradead.org · Supported
- Kernel module
- nvmet_rdma
Check it on the machine
grep -w CONFIG_NVME_TARGET_RDMA /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 nvmet_rdmaPrints 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 as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_NVME_TARGET_RDMA
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.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.67%, higher than 51.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/nvme
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.8 | 5.15.221 | 91cfa74f1f37 |
| 4.8 | 6.1.188 | 156ec10a8be2 |
| 4.8 | 6.6.157 | 9584b3c30e4e |
| 4.8 | 6.12.110 | 5cc3b21729d4 |
| 4.8 | 6.18.52 | ca795fc1d8a1 |
| 4.8 | 7.2.6 | d553a9dc1c45 |
| 4.8 | 7.3 | 0114dd303b37 |
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:NAttack vector, network
- A remote initiator's NVMe capsule with a keyed SGL (NVME_KEY_SGL_FMT_DATA_DESC) is delivered by RDMA RECV into nvmet_rdma_recv_done, which calls nvmet_rdma_map_sgl_keyed; the same peer then raises RDMA_CM_EVENT_DISCONNECTED in nvmet_rdma_cm_handler. nvmet_rdma_enable_port listens with RDMA_PS_TCP on NVME_RDMA_IP_PORT (4420) over RoCEv2/iWARP, which are IP-routable.
- AC:LAttack complexity, low
- The initiator controls both halves: it sends keyed-SGL commands so nvmet_rdma_map_sgl_keyed allocates the SGL and rdma_rw_ctx, then closes the QP so nvmet_rdma_destroy_queue_ib runs while rsp_tags bits remain set because nvmet_rdma_send_done never ran. blktests nvme/061 reproduces this; no uninfluenced race or layout is required.
- PR:NPrivileges required, none
- nvmet_rdma_queue_connect accepts the RDMA CM CONNECT_REQUEST with no authentication. I/O that reaches nvmet_rdma_map_sgl_keyed only needs nvmet_req_init to succeed; nvmet_check_auth_status is true unless a DH-HMAC-CHAP host_key is configured, and nvmet_host_allowed admits a client-supplied host NQN or allow_any_host.
- UI:NUser interaction, none
- The attacker submits the keyed-SGL capsule and disconnects its own RDMA connection; nvmet_rdma_cm_handler delivers RDMA_CM_EVENT_DISCONNECTED into nvmet_rdma_queue_disconnect with no local user or administrator action.
- S:UScope, unchanged
- The leaked sgl_alloc pages and rdma_rw_ctx sit in the nvmet-rdma target kernel's allocator; the bug does not cross a VM, IOMMU, or other security-authority boundary.
- C:NConfidentiality impact, none
- nvmet_rdma_destroy_queue_ib frees the QP without calling nvmet_rdma_free_rsp_resources, so the SGL pages and rdma_rw_ctx are orphaned. Those objects are never copied back to the initiator or otherwise disclosed.
- I:NIntegrity impact, none
- The orphaned scatterlist from nvmet_req_alloc_sgls and the rdma_rw_ctx from rdma_rw_ctx_init are leaked, not reused, so there is no write primitive, use-after-free, or kernel-state corruption.
- A:HAvailability impact, high
- Each in-flight keyed-SGL command leaks the pages sgl_alloc obtained (up to 2^NVMET_RDMA_MAX_MDTS * 4KB, 1MB) plus the rdma_rw_ctx. Repeating RDMA connect, queue-depth READs, and RDMA_CM_EVENT_DISCONNECTED exhausts kernel memory and can OOM the target.