CVE-2026-98479

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux storage networking code lets a malicious disk server secretly replace data a computer is writing, without any error messages or failed operations.

Exploitation: Remote Authenticated
Attacker needs: Low Privilege
Complexity: Moderate
Impact: Data Tampering
Component: OS kernel
Class: Improper Input Validation
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Missing direction validation in iscsi_tcp_hdr_dissect allows a Data-In PDU to be processed for a WRITE command, copying target-supplied bytes into the initiator's scatterlist pages (O_DIRECT user buffers or page cache) instead of rejecting the PDU.

Why it matters to the business

Silent corruption of application or file-system data written over iSCSI, with no errors logged in buffered I/O cases, leading to integrity failures, incorrect results, and difficult-to-diagnose storage inconsistencies.

How an attack unfolds

An attacker who controls or impersonates an iSCSI target answers a WRITE command's ITT with a Data-In PDU containing chosen bytes; the initiator resolves the ITT, skips the missing direction check, and writes the bytes into the pages the application intended to send, completing the write successfully.

How to fix it

Apply the upstream kernel patch that adds an explicit data-direction check before using the scatterlist in the Data-In path of iscsi_tcp_hdr_dissect, matching the existing check in iscsi_tcp_r2t_rsp; update to a kernel containing the fix once released.

How to confirm the fix worked

Confirm the presence of the direction check (e.g., test for DMA_FROM_DEVICE) immediately before the scatterlist copy in the Data-In branch; re-test with a target that emits Data-In for WRITE ITTs to verify rejection.

Typical attack path

Position as or compromise an iSCSI target reachable by the initiator
Receive a WRITE command and its R2T
Reply with a Data-In PDU using the same ITT and attacker-controlled data
Initiator copies data into write scatterlist without direction validation
Write succeeds with corrupted content visible on subsequent reads

How to detect it

Inspect iSCSI initiator logs and tcpdump captures for Data-In PDUs received after an R2T for a WRITE command; compare written blocks against expected content on disk or in cache after pwrite/fsync sequences.

What your security team should do

Prioritize kernel updates for systems using libiscsi_tcp / open-iscsi
Restrict iSCSI traffic to authenticated, isolated storage networks
Monitor for unusual iSCSI PDU sequences or unexpected data in write paths
Audit applications performing O_DIRECT or large buffered writes over iSCSI for data-integrity checks

The record

In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Check the data direction of a Data-In PDU The Data-In branch of iscsi_tcp_hdr_dissect() resolves the ITT to a task and copies the PDU's data segment into that command's scatterlist without asking whether the command was reading. iscsi_tcp_r2t_rsp() in the same file does ask, and rejects an R2T for a command that is not DMA_TO_DEVICE. A target that answers a WRITE command's ITT with a Data-In therefore has the initiator write target-supplied bytes into the pages that write was about to send. Those are the caller's own pinned pages for an O_DIRECT write, and page cache pages for a buffered one. Observed against a test target that emits one 512-byte Data-In naming a 128 KB write's ITT, after the R2T for that write. With O_DIRECT the caller's buffer ends up holding 512 bytes of the target's data while pwrite() returns 131072. Buffered is quieter: pwrite() and fsync() both succeed, nothing is logged, and reading those blocks back returns the target's bytes out of the page cache without a command going on the wire. Check the direction before using the scatterlist, the way the R2T path already does.

Affected packages

Ecosystem	Package	Introduced	Fixed