Cloudanix VulnDB

CVE-2026-90294

High · 7.5

CVSS

7.5

EPSS

0.7%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing flaw in the Linux storage target code can crash the whole system when a fast storage client connects and starts sending commands too quickly.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in IB/isert iSCSI target allows an initiator to issue a SCSI command against an se_session whose se_tpg pointer is still NULL, resulting in a null-pointer dereference and kernel oops inside target_submit when executed from the ib-comp-wq worker.

Why it matters to the business

Systems using iSER over InfiniBand or RoCE for storage can experience sudden kernel crashes and service interruption when an aggressive initiator connects; the defect is present in affected kernel builds until patched.

How an attack unfolds

An attacker acting as an iSCSI initiator completes the login phase; isert_put_login_tx sends the final response before __transport_register_session runs, then immediately issues a SCSI command. The ib_cq_poll_work path reaches iscsit_process_scsi_cmd and target_submit with a NULL se_tpg, triggering the dereference.

How to fix it

Update the Linux kernel to a version containing the fix that moves the final Login Response after __transport_register_session completes; rebuild and reboot affected systems. Where immediate patching is impossible, restrict iSER listeners to trusted initiators or disable iSER in favor of iSCSI-TCP.

How to confirm the fix worked

Confirm the patch is applied by checking the presence of the delayed-response logic in isert_get_rx_pdu and isert_put_login_tx; reproduce login followed by immediate command submission under load and verify absence of the NULL dereference oops.

Typical attack path

  1. Establish iSER connection and perform iSCSI login
  2. Receive final Login Response from isert_put_login_tx
  3. Immediately send SCSI command without waiting for session registration
  4. iscsit_sequence_cmd → iscsit_process_scsi_cmd → target_submit dereferences NULL se_tpg
  5. ib-comp-wq worker oopses, producing kernel panic

How to detect it

Search kernel logs and dmesg for the signature "general protection fault" combined with "target_submit" and "ib_cq_poll_work"; examine call traces containing isert_recv_done, iscsit_process_scsi_cmd, and KASAN null-ptr-deref at offset 0x78 in se_session.

  • target_submit+0xbe/0x390
  • ib_cq_poll_work
  • KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
  • isert_recv_done
  • Oops: general protection fault, probably for non-canonical address

What your security team should do

  • Prioritize kernel update on all hosts exposing iSER targets
  • Add kernel oops monitoring for target_submit and isert_recv_done signatures
  • Temporarily firewall iSER ports (3260/RDMA) from untrusted initiators until patched
  • Test discovery sessions and real HCAs after upgrade as they were not covered by the original reproducer

The record

In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.

Affected packages

Ecosystem Package Introduced Fixed