Look up another CVE · open CVE-2026-90293 in the interactive tracker
CVE-2026-90293
IB/isert: post the full-feature receive buffers after session registration
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-90293 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
isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.
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/ulp/isert/ib_isert.c
- What this is
- ISCSI EXTENSIONS FOR RDMA (ISER) TARGETMAINTAINERS section matched on drivers/infiniband/ulp/isert · linux-rdma@vger.kernel.org · Supported
- Kernel module
- ib_isert
Check it on the machine
grep -wE 'CONFIG_INFINIBAND|CONFIG_INFINIBAND_ISERT' /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 ib_isertPrints 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.
- bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_INFINIBAND, CONFIG_INFINIBAND_ISERT
- 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.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.69%, higher than 51.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 |
|---|---|---|
| 3.10 | 5.10.270 | 962edb9a6b0d |
| 3.10 | 5.15.221 | 068fe9841d25 |
| 3.10 | 6.1.188 | d4f8257c3283 |
| 3.10 | 6.6.157 | 9c21a4330222 |
| 3.10 | 6.12.110 | 9b2c61344992 |
| 3.10 | 6.18.52 | 6c506fee5a5f |
| 3.10 | 7.2.6 | ad4492dcaf90 |
| 3.10 | 7.3 | 5247dde9daac |
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
- The trigger is an ISCSI_OP_SCSI_CMD RDMA Send that isert_recv_done() handles after isert_put_login_tx() has already called isert_post_recvm() on the full-feature RQ; those Sends arrive from a remote initiator on the QP accepted by isert_connect_request() after rdma_listen() in isert_setup_id(), which binds RoCEv2 (UDP/IP) or iWARP (TCP).
- AC:LAttack complexity, low
- The initiator drives login until login_complete so isert_put_login_tx() posts RX buffers, then sends ISCSI_OP_SCSI_CMD without waiting for the Login Response; isert_rdma_accept() sets rnr_retry_count=7 so IB/RoCE retries that Send until the RQ is filled and isert_recv_done() runs on ib-comp-wq before iscsi_post_login_handler() calls __transport_register_session().
- PR:NPrivileges required, none
- login_complete is set in iscsi_target_do_login CSG1 only after iscsi_conn_authenticated(); when tpg_attrib.authentication is 0, iscsi_handle_authentication() accepts AuthMethod=None with no secret, and generate_node_acls demo mode lets core_tpg_check_initiator_node_acl() admit a client-asserted InitiatorName.
- UI:NUser interaction, none
- The attacker is the iSER initiator that finishes the Login Request exchange and posts the early SCSI Command on its own QP; no local user or administrator action is required.
- S:UScope, unchanged
- The NULL se_sess->se_tpg load in target_submit() oopses the same kernel that runs ib_isert; no VM, IOMMU, or sandbox boundary is crossed.
- C:NConfidentiality impact, none
- transport_alloc_session() kmem_cache_zallocs se_session so se_tpg stays NULL until __transport_register_session(); target_submit() only loads se_tpg->se_tpg_tfo and takes a GPF, with no out-of-bounds read.
- I:NIntegrity impact, none
- The fault is a NULL load of se_cmd->se_sess->se_tpg in target_submit(); this path does not write kernel memory or reuse a freed object.
- A:HAvailability impact, high
- KASAN reports a null-ptr-deref in target_submit() on ib-comp-wq (ib_cq_poll_work → isert_recv_done → iscsit_process_scsi_cmd → iscsit_execute_cmd), producing a kernel oops.