Cloudanix VulnDB

CVE-2026-90413

Critical · 9.1

CVSS

9.1

EPSS

0.8%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's handling of certain network storage login messages could let a remote attacker read a small amount of kernel memory or crash the system.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds kernel memory read in iSER login PDU handling when a declared DataSegmentLength exceeds the actual bytes placed in the receive buffer, allowing controlled-size reads past an 8 KiB allocation before authentication.

Why it matters to the business

Systems using RDMA-based iSCSI (iSER) face risk of kernel crashes or limited memory disclosure from unauthenticated remote initiators, potentially causing service outages or exposure of kernel memory contents; urgency is moderate given low exploit maturity and no known in-the-wild use.

How an attack unfolds

An unauthenticated remote initiator establishes an iSER connection and sends a login PDU (first or subsequent) whose BHS declares a DataSegmentLength larger than the bytes actually received; the kernel copies the declared length from the fixed-size buffer, triggering a KASAN-detected slab-out-of-bounds read during kmemdup_nul in portal lookup or text processing.

How to fix it

Update the Linux kernel to a version containing the fix that rejects login PDUs where declared dlength exceeds received login_req_len; the check must be present in both isert_get_login_rx and isert_login_recv_done paths.

How to confirm the fix worked

Confirm the presence of the length comparison (dlength <= login_req_len) in isert login receive functions and verify that crafted PDUs no longer produce slab-out-of-bounds reports under KASAN.

Typical attack path

  1. Establish RDMA connection to iSER target
  2. Send first login PDU with inflated DataSegmentLength but short payload
  3. Trigger isert_rx_login_req and subsequent iscsi_target_locate_portal or iscsi_decode_text_input path
  4. Cause out-of-bounds read from kmalloc-8k slab

How to detect it

Review kernel logs for KASAN slab-out-of-bounds reports citing kmemdup_nul, iscsi_target_locate_portal, or iscsi_decode_text_input triggered by isert_login paths; correlate with iSER connection attempts from untrusted initiators.

  • BUG: KASAN: slab-out-of-bounds in kmemdup_nul
  • Read of size 8193 at addr
  • iscsi_target_locate_portal
  • iscsi_decode_text_input
  • isert_login_recv_done
  • isert_login_wq

What your security team should do

  • Prioritize kernel updates on any hosts exposing iSER/RDMA iSCSI targets
  • Disable iSER interfaces if RDMA iSCSI is not required
  • Monitor for kernel oops or KASAN reports involving isert_login_recv_done or iscsi_target_locate_portal

The record

In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), payload_length = ntoh24(login_req->dlength); tmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.

Affected packages

Ecosystem Package Introduced Fixed