A rogue storage target can point at a random task on the initiator and make the kernel clean it up like a concierge discarding the wrong guest's luggage
The Linux kernel's libiscsi handler for iSCSI Reject PDUs copies the rejected header verbatim and trusts the ITT (Initiator Task Tag) inside it. iscsi_itt_to_task() only bounds the index against cmds_max; it does not verify that the slot holds an active task or that task->conn is non-NULL. A malicious iSCSI target can therefore name any pool slot: an unused slot dereferences a NULL task->conn, a freed slot underflows a refcount, and an in-flight SCSI command is marked successful even though its buffer was never written. Affected versions include Linux kernel through 6.18.58 and 7.2.12; fixes are in 6.18.59 and 7.2.13 (and distro backports).
Vendor severity says CRITICAL 9.8, but that vector models a remote unauthenticated attacker with full CIA impact. The actual boundary is a client-side initiator parsing a malicious response from the storage server; impact tops out at host crash and silent read corruption on that initiator, not code execution or data theft. The severity should be reassessed HIGH for high-value iSCSI consumers rather than blanket CRITICAL for every Linux host.
6 steps from start to impact.
Attacker gains control of, or position to MITM, an iSCSI target
- Attacker can respond to iSCSI initiator as the target
- Victim has a libiscsi iSCSI session to that endpoint
- Enterprise iSCSI normally runs on dedicated storage networks and trusts only known arrays
- CHAP (especially mutual CHAP) may prevent unknown targets from completing login
- Physical/network access to storage path is restricted
Victim creates an iSCSI session and sends SCSI commands
- Linux host runs vulnerable libiscsi
- At least one iSCSI command is in flight or pool has returned slots
- iSCSI initiators are common on Linux but not typically exposed to untrusted storage
Attacker sends an iSCSI Reject PDU with a reflected ITT it controls
iscsi_handle_reject() copies that and extracts the ITT without checking whether it points to a valid in-flight task.- Attacker can craft a Reject PDU and deliver it during the session
- Target is allowed to send protocol-level PDU rejects
- Trigger requires deliberate malicious target behavior; normal storage arrays don't send crafted rejects
iscsi_itt_to_task() resolves an arbitrary pool slot
- Victim kernel lacks the validating patch
- Crafted ITT selects an unused, free, or in-flight task
- No additional attacker capability required once target can send the PDU
Kernel null deref / refcount underflow or silent success of an in-flight read
iscsi_nop_out_rsp() dereferences task->conn leading to general protection fault. For freed task, WARN_ON and refcount underflow occur. For an in-flight SCSI read, the task is completed as successful without writing the buffer, so the read returns 1048576 with uninitialized data.- Crafted ITT matches one of the problematic states
- The most severe silent corruption requires an in-flight command to be targeted; crash states are easier to hit but still require malicious target
Repeated Reject PDUs pull down or corrupt connected initiators
- Multiple hosts mount the same malicious iSCSI target
- Target persists and continues sending rejects
- Requires storage fabric compromise or rogue target that many systems use
- Most iSCSI deployments have limited fan-out to a single untrusted target
libiscsi kernel or distro backport. For HIGH, noisgate mitigation SLA is ≤30 days and remediation is ≤180 days; patching earlier removes the parser flaw entirely.iscsi_nop_out_rsp WARNs and silent read anomalies — Enable kernel log collection for WARN_ON_ONCE and filesystem/application checksum failures on iSCSI-backed volumes to detect exploitation attempts. This is detection, not prevention.- Generic network firewalls/WAFs do not parse iSCSI Reject PDUs deeply and won't catch a crafted ITT from an authorized storage endpoint.
- Initiator-only CHAP does not authenticate the target; it only proves the initiator to the target, so it does not stop a rogue target unless mutual CHAP is explicitly configured.
- EDR/antivirus signature scanning on the host is unlikely to intercept a kernel malformed storage protocol parser flaw before crash/corruption.
The supporting signals.
| In-the-wild status | No active exploitation observed; not in CISA KEV as of provided data. |
|---|---|
| Proof-of-concept availability | Kernel patch/commit contains enough detail to reproduce; no standalone public exploit PoC observed in VulDB/Tenable/CIRCL results. |
| EPSS score | 0.00552 (very low 30-day predicted exploit probability); percentile not retrieved from source. |
| KEV status | Not listed in CISA KEV. |
| CVSS v3.1 vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — vendor vector; overstates attacker position and impact. |
| Affected versions | Linux kernel libiscsi before fix; VulDB lists vulnerable through 6.18.58 and 7.2.12. |
| Fixed versions | 6.18.59 and 7.2.13 upstream; distro backports expected. |
| Exposure data | No public Shodan/Censys/GreyNoise exposure data in the supplied search results; iSCSI is normally internal. |
| Disclosure date | 2026-10-28 (CVE assigned 2026-09-25). |
| Reporting researcher/org | Resolved in Linux kernel (patch 7215a69b6456fda79c0935c2959045dff3fcaac8 or backports); no external reporter named in VulDB. |
Sources.
Why this verdict
- Role multiplier: Linux hypervisors, database servers, and backup appliances using iSCSI block storage can be killed or forced to accept corrupted reads by a malicious target; that high-value data-plane share keeps the floor at HIGH.
- Attacker position: The attacker must be the iSCSI target or positioned to MITM the storage session. That is not an internet-facing unauthenticated remote path—it implies a compromised storage array, insider, or network-level interception.
- Vendor severity mismatch: The supplied 9.8 CRITICAL vector assigns full confidentiality/integrity/availability impact, but the bug provides no code execution, credential theft, or confidentiality loss; it is an initiator-side availability/data-integrity fault.
- Friction audit: Default segmentation, trusted storage arrays, CHAP/mutual CHAP, and lack of arbitrary iSCSI target connections all shrink the reachable population.
Why not higher?
It doesn't reach CRITICAL because libiscsi is not a canonical security boundary like an IdP, hypervisor, or edge platform by definition, and the attacker must already control the storage target or intercept storage traffic. No code execution or lateral movement is documented, so a fleet-wide domain/persistence impact isn't supported.
Why not lower?
It can't fall to MEDIUM with the high-value iSCSI consumers in view: a single malicious target can simultaneously crash or silently corrupt reads on multiple hypervisors/database servers connected to it. That chokepoint, once controlled, turns a client-side flaw into a fleet availability/data-integrity event, so the floor remains HIGH.
Crowdsourced verification payload.
Run on each Linux host that may mount or boot from an iSCSI target. Invoke as root: bash /tmp/check_CVE-2026-99153.sh. Requires root to read lsmod; if libiscsi is not loaded, the result is UNKNOWN.
#!/usr/bin/env bash
# Check for CVE-2026-99153 (libiscsi ITT validation) on a Linux host.
# Run as root on each iSCSI initiator host.
set -u
if ! lsmod | grep -q '^libiscsi\b'; then
echo "UNKNOWN: libiscsi module not loaded; iSCSI initiator may not be active"
exit 2
fi
KREL=$(uname -r)
KVER=${KREL%%-*}
ver_ge() {
# Returns 0 if $1 >= $2 using version sort
high=$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)
[ "$high" = "$1" ]
}
patched=no
case "$KVER" in
7.*)
ver_ge "$KVER" "7.2.13" && patched=yes
;;
6.*)
ver_ge "$KVER" "6.18.59" && patched=yes
;;
[8-9]*|1[0-9]*)
patched=yes
;;
*)
patched=no
;;
esac
if [ "$patched" = "yes" ]; then
echo "PATCHED: kernel $KREL is at or above a fixed upstream stable version"
exit 0
fi
echo "VULNERABLE: kernel $KREL is below fixed upstream versions (6.18.59 / 7.2.13); verify distro backport for CVE-2026-99153"
exit 1