---
id: "CVE-2026-98479"
kind: "vulnerability"
aliases: ["CVE-2026-98479"]
title: "Linux kernel iSCSI: malicious target can overwrite write buffers"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "iscsi", "kernel", "linux", "self-hosted", "storage"]
not_affected_if: ["managed-hosting", "no-iscsi"]
published_at: "2026-10-18T16:16:58+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:25:53+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98479", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel iSCSI: malicious target can overwrite write buffers

The Linux kernel iSCSI TCP initiator accepted a Data-In PDU for a command that was writing, so a malicious or compromised iSCSI target can inject its own bytes into the initiator's write buffers. The result is silent data corruption in O_DIRECT and page-cache writes, with the target's data read back from the cache.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the kernel version that includes the iscsi_tcp Data-In direction fix in the vendor's advisory
- Check whether the iSCSI initiator module is loaded with `lsmod | grep libiscsi_tcp`
- Check for active iSCSI sessions with `iscsiadm -m session`

## Fix

- Update the Linux kernel to a release that includes the upstream libiscsi_tcp direction check (version unknown from these sources)
- Restrict iSCSI targets to trusted hosts until patched

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98479

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_