Linux kernel libiscsi_tcp: a Data-In PDU naming a WRITE command's ITT overwrites the writer's own pages

Impact

The iSCSI initiator resolves the ITT of an incoming Data-In PDU to a task and copies the PDU payload into that command's scatterlist without checking that the command was a read. A target that answers a WRITE command's ITT with a Data-In therefore makes the initiator scribble target-supplied bytes into the pages the write was about to send: the caller's own pinned buffer for an O_DIRECT write, page cache pages for a buffered one. This is silent data corruption, not a crash - the reporter observed pwrite() returning the full 131072 bytes while 512 bytes of target data sat in the caller's buffer, and in the buffered case pwrite() and fsync() both succeeded, nothing was logged, and reading the blocks back returned the target's bytes out of page cache without a command ever going on the wire. On a GPU fleet that mounts iSCSI LUNs for checkpoints, datasets or scratch, that means corrupt checkpoints and corrupt training data that pass every write-side check and only surface much later. The R2T path in the same file already does the direction check; the Data-In path did not.

Who can reach it

The iSCSI target the node logs into, or anyone who can impersonate or MITM it on the storage network - iSCSI sessions are frequently run with CHAP off on a flat storage VLAN. No initiator-side authentication bypass is needed: the malformed PDU is accepted on an already-established session. Not reachable from a tenant GPU pod unless that tenant can also reach or control a target the host logs into.

What to do

Take the stable kernel release carrying the direction check (five stable branches were fixed; pick the one matching your tree) and reboot each node - the fix is in the in-tree iscsi_tcp/libiscsi_tcp path, so there is no module reload or runtime toggle that avoids the reboot. Until then, the usable mitigation is network-level: restrict which targets initiators may log into, require mutual CHAP, and keep the storage VLAN off any tenant-reachable network. No fixed distro version is named in the record beyond the stable commits.

References

Related entries

• Linux kernel nvmet: metadata SGL allocation failure frees the data SGL against an unassigned p2p deviceCVE-2026-98964 · Linux kernel nvmet (P2P device handling in nvmet_req_alloc_p2pmem_sgls error path)High
• Linux kernel ice: relaxed Tx doorbell write on arm64 trips a BUG_ON in dql_completed and panics the hostCVE-2026-98965 · Linux kernel ice driver (Tx doorbell MMIO ordering on arm64)High
• Linux kernel libiscsi: a malicious iSCSI target crashes the initiator with an unsolicited NOP-InCVE-2026-99152 · Linux kernel libiscsi (__iscsi_complete_pdu management-response task lookup)High
• OpenSSL: ChaCha20-Poly1305 accepts 16-byte nonces, silently ignoring leading bytesCVE-2019-1543 · OpenSSL (ChaCha20-Poly1305 variable nonce length)High
• Linux kernel (overlayfs, Ubuntu patch): OverlayFS file-capability privilege escalationCVE-2021-3493 · Linux kernel (overlayfs, Ubuntu patch)High
• OpenSSL: X.400 address type confusion in X.509 GeneralNameCVE-2023-0286 · OpenSSLHigh