CVE-2026-53176

What it actually does

This is a remotely reachable Linux kernel flaw in the iSER target path. During iSER login handling, the kernel subtracts the fixed iSER header length from the received work-completion byte count without first verifying that the packet is at least that long. A short unauthenticated login PDU can make the calculated login request length negative; that negative signed value is later converted to a very large unsigned memcpy length, causing an out-of-bounds copy into an 8192-byte login request buffer. The expected practical result is a kernel fault and crash of the storage target node, producing a remote pre-authentication denial of service against systems exposing iSER target functionality.

Why it matters to the business

An attacker with network reachability to an affected iSER/RDMA storage target can crash the Linux host before authentication occurs. In operational terms, this can interrupt block storage access, disrupt virtualization clusters, databases, backup platforms, or other systems dependent on iSCSI/iSER-backed storage. EPSS is currently low and there is no known KEV listing or public exploit maturity reported, but the vulnerability is simple in concept and affects a kernel-facing pre-authentication path, so exposed storage networks should still be treated as high priority for remediation.

How an attack unfolds

An attacker first identifies a Linux host exposing iSER target services over an RDMA-capable path such as InfiniBand, RoCE, or iWARP. Instead of completing a normal iSCSI/iSER login, the attacker sends a deliberately malformed login Send work request whose total received byte length is less than the expected 76-byte iSER header size. Because this occurs before iSCSI authentication, valid storage credentials are not required. The vulnerable kernel code subtracts the header size from the shorter received length, producing a negative login payload length. That value survives subsequent signed comparisons and is eventually passed to memcpy as a size_t, where it becomes a very large copy length. The oversized copy overruns the login request buffer and faults in kernel context, typically crashing or panic-resetting the target node and interrupting dependent storage workloads.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the fix for the iSER target login length check, specifically rejecting login PDUs shorter than ISER_HEADERS_LEN before subtracting the header length. If a fixed kernel package is not yet available, mitigate by disabling iSER target functionality where it is not required, unloading or blacklisting the ib_isert module, and restricting RDMA/iSER access to trusted storage initiator networks only. Network-layer controls should limit exposure of iSCSI/iSER paths, including TCP/3260 where applicable for iWARP/iSCSI discovery and any RDMA fabrics used for storage. Authentication alone is not a sufficient mitigation because the vulnerable path is reachable before iSCSI authentication. Reboot into the fixed kernel, or apply an approved live patch if provided by the operating system vendor.

How to confirm the fix worked

Confirm the running kernel contains the vendor patch that rejects login receive completions with byte_len less than ISER_HEADERS_LEN before computing the login payload length. On source-based or custom kernels, inspect drivers/infiniband/ulp/isert/ib_isert.c and verify the lower-bound check exists in or before isert_login_recv_done(). Confirm the active kernel version matches the fixed package from the operating system vendor after reboot. If mitigating instead of patching, verify the ib_isert module is not loaded and cannot autoload, and confirm no iSER target portals are active. From a network perspective, validate that only trusted initiators can reach iSER/RDMA storage services. In a controlled lab only, negative testing with a malformed short login PDU should be rejected without kernel warnings, oopses, panics, or target service interruption.

Typical attack path

1. Discover hosts exposing iSER/RDMA storage target functionality on reachable storage or data-center networks.
2. Establish RDMA/iSER communication with the target sufficiently to reach the login receive path.
3. Send a malformed iSER login PDU shorter than ISER_HEADERS_LEN, which is 76 bytes.
4. Trigger signed integer underflow in the login request length calculation.
5. Cause the negative length to be converted into a very large memcpy size.
6. Crash the Linux kernel or iSER target node, disrupting storage service availability.

How to detect it

Detection should focus on kernel crash artifacts and iSER target logs because the malformed packet may not produce a clean application-layer audit event before the host faults. Review journald, syslog, dmesg, netconsole, kdump/vmcore analysis, hardware management logs, and storage target service logs for kernel oopses, panics, or general protection faults involving ib_isert, isert_login_recv_done(), or isert_rx_login_req(). Correlate crashes with RDMA/iSER connection attempts from unusual initiators, unexpected storage network peers, or repeated short-lived login attempts. In environments using kdump, inspect vmcore backtraces for the vulnerable call path and oversized memcpy behavior. Network telemetry may be limited on InfiniBand/RoCE fabrics, but where flow logs, switch telemetry, packet capture, or RDMA connection manager logs are available, look for previously unseen initiator addresses connecting to iSER/iSCSI target services shortly before a crash. Absence of logs does not rule out exploitation because a successful denial-of-service attempt may panic the kernel before events are flushed to disk.

• ib_isert
• isert_login_recv_done
• isert_rx_login_req
• ISER_HEADERS_LEN
• kernel BUG
• BUG: kernel NULL pointer dereference
• general protection fault
• Unable to handle kernel paging request
• Oops:
• Kernel panic
• RIP: memcpy
• RIP: __memcpy
• RIP: isert_rx_login_req
• RIP: isert_login_recv_done
• Call Trace: isert_login_recv_done
• Call Trace: isert_rx_login_req
• drivers/infiniband/ulp/isert/ib_isert.c
• TCP/3260

What your security team should do

• Inventory Linux systems that act as iSER or RDMA-backed iSCSI targets, prioritizing storage nodes supporting virtualization, databases, backup, or clustered workloads.
• Patch affected kernels as soon as vendor updates are available; prioritize internet-exposed, cross-zone, or broadly reachable storage fabrics even though current EPSS and known exploitation signals are low.
• If iSER is not required, disable the ib_isert module and remove iSER target configuration rather than relying on authentication controls.
• Restrict RDMA/iSER access to dedicated storage networks and explicitly allow only approved initiator hosts.
• Review kernel logs and crash artifacts for signs of recent iSER-related faults, especially unexplained panics involving ib_isert, isert_login_recv_done(), or isert_rx_login_req().
• Add monitoring for unexpected kernel crashes or storage target resets correlated with inbound RDMA/iSER connection attempts.
• Ensure HA/failover behavior for storage targets is tested, because exploitation primarily creates an availability failure.