CVE-2026-90294: IB/isert: delay the final Login Response until the session is registered
In the Linux kernel, the following vulnerability has been resolved:
IB/isert: delay the final Login Response until the session is registered
isertputlogintx() puts the final Login Response on the wire before transportregistersession(), which iscsipostloginhandler() reaches only after iscsitargetdologin() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an sesession whose setpg 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, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ibcqpollwork RIP: 0010:targetsubmit+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> ? pfxrawspinlockbh+0x10/0x10 ? pfxtargetsubmit+0x10/0x10 ? mutexlock+0x81/0xe0 ? pfxmutexlock+0x10/0x10 ? iscsitexecutecmd+0x650/0x850 iscsitsequencecmd+0x186/0x3d0 iscsitprocessscsicmd+0x87/0x300 isertrecvdone+0x1002/0x2390 ? pfxisertrecvdone+0x10/0x10 ? rxepollcq+0x253/0x3d0 ? finishtaskswitch.isra.0+0x1dc/0xa70 ibprocesscq+0xe1/0x390 ibcqpollwork+0x46/0x150 processonework+0x633/0x1030 ? assignwork+0x11d/0x370 workerthread+0x45b/0xd10 ? pfxworkerthread+0x10/0x10 ? pfxworkerthread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalcsigpending+0x15c/0x1e0 ? pfxkthread+0x10/0x10 retfromfork+0x36e/0x5a0 ? pfxretfromfork+0x10/0x10 ? switchto+0x572/0xdd0 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---
Delay the final Login Response instead. isertgetrxpdu() runs from iscsitargetrxthread() after conn->rxlogincomp, completed by iscsipostloginhandler() after transportregistersession(); 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 isertconn, not in the struct iscsilogin that iscsitargetnegorelease() 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 Software
Event History
Frequently Asked Questions
What does an attacker need to do to trigger the crash?
An iSER initiator must send a SCSI command immediately after receiving the final Login Response, before the target has registered the session. This can cause command processing against a session whose se_tpg pointer is still NULL.
What is the operational impact if the issue is triggered?
The kernel can oops in the ib-comp-wq workqueue while processing the command, due to a NULL-pointer dereference in target_submit. The supplied trace identifies the worker as ib_cq_poll_work.
How can I identify a likely occurrence in logs or crash reports?
Look for a general protection fault or KASAN null-pointer-dereference report involving target_submit, with ib-comp-wq and ib_cq_poll_work in the workqueue context. The fault may reference an access in the range 0x78 through 0x7f from a NULL pointer.