CVE-2026-90293
High · 7.5CVSS
7.5
EPSS
0.7%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A timing flaw in the Linux kernel's remote storage code lets an attacker crash servers by sending commands at exactly the wrong moment during connection setup.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in iSER login handling allows an initiator to submit a SCSI command against an se_session whose se_tpg pointer is still NULL, causing a kernel oops in target_submit.
Why it matters to the business
Remote unauthenticated attackers can crash affected Linux kernel systems over the network, producing denial of service and potential loss of storage connectivity or availability.
How an attack unfolds
An attacker initiates an iSER login, sends the final Login Request, then immediately issues a SCSI command without waiting for the Login Response; because receive buffers are posted too early, the command is processed against an incompletely registered session and triggers the NULL dereference.
How to fix it
Apply the upstream kernel commit that moves full-feature receive buffer posting to isert_get_rx_pdu() after session registration; rebuild and reboot with the fixed kernel.
How to confirm the fix worked
Confirm the patched isert.c contains the buffer-post logic inside isert_get_rx_pdu() prior to sending the final Login Response; run the provided login-cycle test harness and verify zero oopses occur when the initiator does not wait.
Typical attack path
- Establish RDMA connection to iSER target
- Send iSER login requests up to final Login Request
- Immediately transmit a SCSI command before receiving Login Response
- Kernel processes command against unregistered session and oopses
How to detect it
Review kernel logs for oops traces referencing target_submit and isert; correlate with iSER login activity and RDMA connection events around the crash time.
What your security team should do
- Prioritize kernel update on all systems exposing iSER/RDMA targets
- Monitor vendor or distribution security feeds for the backported fix
- Temporarily restrict iSER access to trusted initiators until patched
The record
In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration 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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|