CVE-2026-99153: The iSCSI Reject PDU That Trusted Its Own Reflection

A Reply That Names Its Own Victim

iSCSI carries SCSI storage commands over TCP. When an initiator (the client, such as a server mounting a remote disk) sends a command, it stamps the request with an Initiator Task Tag (ITT), and responses are matched back to requests by that tag. RFC 7143 says the ITT must be unique for the life of a task.

A Reject PDU is how a target reports a protocol error. The RFC describes it as including the complete header of the bad PDU. The kernel's iscsi_handle_reject() copies that header and reads the ITT from it to find the task it should clean up.

The ITT inside a Reject is only a reflection of what the target says it received, and the target controls it. The kernel was treating that reflected value as trustworthy.

The Vulnerability at a Glance

The CNA text does not name a CWE, and OpenCVE currently shows none. A CWE-20 and CWE-416 pairing was added on October 28 and removed on October 31.

Who Attacks Whom

The attacker in this scenario is the iSCSI target, the storage server. The victim is the initiator, the Linux host consuming the storage. The CVSS scenarios say the forged ITT rides inside the Reject PDU data over routable TCP.

The "no privileges, no user interaction" rating needs context. The scenarios say the receive callbacks are installed before the session is marked logged in, and that the Reject handler imposes no login-state or authentication check. A target can therefore trigger the fault during login without credentials.

The initiator still has to be configured to connect to that target. Halo Security rates external exposure likelihood 1 of 5, because iSCSI is meant to run inside trusted storage networks and not be exposed to the internet.

The practical threat model is therefore a malicious, compromised, or impersonated storage target, or an attacker positioned to inject traffic into an iSCSI session. It is not an anonymous scan of the open internet.

What the Bug Does

The kernel description explains the mechanism. iscsi_itt_to_task() bounds the index against cmds_max and checks nothing else, so any task in the pool can be named. iscsi_nop_out_rsp() then completes it. Three outcomes follow:

The included trace shows the crash path: a KASAN null-pointer dereference in iscsi_nop_out_rsp, reached from __iscsi_complete_pdu, iscsi_tcp_recv_skb, and the TCP receive path.

The third outcome is the most worrying. A host can believe a read succeeded when no data arrived, which is a data-integrity failure and not just a crash.

Why 9.8 Needs Reading Carefully

The CNA's scenario text justifies each metric.

• Availability: one crafted Reject can oops or panic the host by hitting an unused slot.
• Integrity: an observed in-flight task can be falsely completed, and WRITE commands can be acknowledged without being committed.
• Confidentiality: an untouched READ buffer can be exposed as valid data, so non-zeroed page-cache folios may show up as file contents.
• Complexity: a target sees live ITTs and can withhold their responses, and index 1 in a fresh pool deterministically has a NULL connection. No race is required.

A 9.8 base score assumes the attacker is the network peer, and here the peer is the storage server. For a host that trusts its SAN, the real-world risk depends on how trustworthy and isolated that SAN is.

What the Evidence Does Not Show

Some third-party text overstates the impact.

OpenCVE's AI-generated analysis calls this "kernel memory corruption leading to potential remote code execution" and says the Reject PDU is sent "to a Linux iSCSI target." That wording reverses the roles: the kernel description has the target sending the Reject to the initiator. It also asserts code execution, which the kernel description does not demonstrate.

KernelScan's AI analysis likewise labels the bug a use-after-free with potential code execution. That classification is probably why OpenCVE briefly listed CWE-416 before removing it.

What the kernel record actually documents:

• A NULL-pointer dereference crash, with a captured oops
• A refcount underflow on a freed task
• False successful completion of an in-flight command

Code execution is not demonstrated, and it is not ruled out for all configurations. Treat it as an unsupported claim until a primary source shows it.

The kernel scenario text also states Scope: Unchanged. The fault stays within the initiator host kernel and does not cross a VM or IOMMU boundary.

Affected and Fixed Versions

The record marks the bug as present since kernel 2.6.32, with fixes in each maintained branch.

Source: .

Every kernel from 2.6.32 up to the branch fix is flagged vulnerable by the CPE ranges. The CVE record lists eight fix commits across stable branches. KernelScan's table shows only three branches, which is consistent with the record but incomplete.

Distribution kernels backport fixes and often keep older version numbers. A host on an enterprise kernel needs a vendor advisory, not just a version comparison.

KernelScan also reports that several Civil Infrastructure Platform trees, including 4.4, 4.19, 5.10, 6.1, and 6.12, had no CIP fix yet at its capture time.

The Fix

The kernel description says the patch validates the reflected ITT "the way iscsi_itt_to_ctask() validates a command ITT." It also requires the task to be in flight and not a SCSI command. [S1] KernelScan summarizes this as three checks: the ITT passes standard verification, the task is not in the FREE state, and it is not a SCSI command (task->sc is NULL).

In short, the initiator now confirms that a rejected task really is a NOP-Out it sent and is still outstanding. It no longer takes the target's word for it.

This matches the protocol. RFC 7143 says targets must not implicitly terminate an active task by sending a Reject for a PDU exchanged during the task's life. A conforming target would not send the Reject this attack depends on, and a hardened initiator should not assume every target conforms.

What Administrators Should Do

1. Inventory iSCSI use. Find hosts using the software iSCSI initiator (iscsi_tcp), and confirm which targets they connect to.
2. Map trust. Confirm every target is controlled by you and that the storage network is isolated from untrusted segments. Halo's guidance is to verify segmentation and then patch on the normal kernel lifecycle.
3. Patch the kernel. Update to a fixed release for your branch, or to your vendor's kernel containing the backport. OpenCVE's AI recommendation names commit 7215a69b6456 for the 6.18 line.
4. Restrict iSCSI traffic to trusted internal networks if an immediate update isn't possible.
5. Plan the reboot. A kernel update needs a reboot unless the vendor offers live patching.

Hosts that don't use iSCSI at all are far less likely to be reachable, though the code lives in a common library.

Detection and Post-Incident Checks

• Kernel logs: look for oopses in iscsi_nop_out_rsp, WARN_ON_ONCE traces from iscsi_complete_task, and unexpected session resets.
• Storage integrity: if a suspect target was connected, consider running filesystem checks and comparing against known-good copies. The false-completion path can leave silent corruption without a visible warning.
• Target provenance: verify the target's identity, addressing, and network path, and rotate any exposed iSCSI authentication secrets.

Absence of a crash does not prove absence of silent data errors.

Timeline

What Remains Uncertain

• Code execution is not established. Only crash and false-completion behavior is documented.
• Real-world exploitability depends on reaching the initiator as a target. Halo rates internet exposure unlikely.
• EPSS and KEV are time-specific. Both show low activity now.
• The patch code was not independently reviewed here. The kernel.org commit pages were not retrievable.
• Distribution status varies. Backports may fix systems that still report older version numbers.

Frequently Asked Questions

Can anyone on the internet exploit this? Not directly. The attacker must be, or impersonate, the iSCSI target an initiator connects to.

Is it remote code execution? Not as documented. The kernel record shows a crash and false completion, and RCE claims come from AI-generated summaries.

Which is worse, the crash or the silent corruption? The crash is loud and recoverable. The false-success path is quieter and can cause integrity problems that surface later.

Does it affect iSCSI targets? The described flaw is in the initiator-side libiscsi Reject handling. Some secondary text confuses the roles.

Does "KEV: No" mean it's safe? No. It only means no exploitation was recorded in that catalog at capture time.

---

Sources

• [S1] OpenCVE record, CVE-2026-99153: https://app.opencve.io/cve/CVE-2026-99153
• [S2] RFC 7143, iSCSI (Consolidated): https://datatracker.ietf.org/doc/html/rfc7143
• [S3] Halo Security advisory: https://cve.halosecurity.com/cve-advisory/cve-2026-99153-linux-kernel-libiscsi-reject-pdu-validation-flaw
• [S4] KernelScan, CVE-2026-99153: https://kernelscan.io/cve/CVE-2026-99153

---

#Linux #LinuxKernel #iSCSI #CVE202699153 #Cybersecurity #StorageSecurity #PatchManagement