CVE-2026-90294

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.