{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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 \u003c80\u003e 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:   \u003cTASK\u003e   ? __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   \u003c/TASK\u003e  Modules linked in:  ---[ end trace 0000000000000000 ]---  Delay the final Login Response instead.  isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn-\u003erx_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.",
  "id": "DEBIAN-CVE-2026-90294",
  "modified": "2026-09-18T04:47:35.503729621Z",
  "published": "2026-09-17T17:17:26.693Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90294"
    }
  ],
  "upstream": [
    "CVE-2026-90294"
  ]
}