Description

In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: senselen = get_unaligned_be16(data); if (datalen < senselen) goto invalid_datalen; memcpy(sc->sense_buffer, data + 2, min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-15T13:18:01.160Z",
  "pubdate": "2026-08-15T13:18:01.160Z",
  "executiveSummary": "An information disclosure vulnerability exists in the Linux kernel's iSCSI subsystem, specifically within the libiscsi module. The flaw resides in the iscsi_scsi_cmd_rsp() function during the handling of SCSI Response sense data from targets. The vulnerability type is an out-of-bounds read leading to a stale-data leak into the SCSI sense buffer.\nThe impact of this vulnerability allows unauthorized userspace applications to read sensitive memory contents, potentially exposing kernel or connection-specific data previously stored in the connection data buffers. The affected systems are any Linux kernel implementations utilizing the libiscsi subsystem.\nThe risk implications involve the potential exposure of sensitive kernel memory to user space via the SCSI command sense buffer. An attacker capable of acting as a malicious iSCSI target or performing man-in-the-middle manipulation of iSCSI traffic can trigger the condition. Exploitation requires the ability to supply a crafted SCSI Response data segment where the data length improperly accounts for the 2-byte sense length prefix.",
  "technicalDetails": "The vulnerability stems from improper bounds checking in the iscsi_scsi_cmd_rsp() function located in the Linux kernel source file managing the iSCSI SCSI command response processing. The target-supplied data segment for a SCSI Response begins with a 2-byte sense length prefix followed immediately by the actual sense bytes. Therefore, the total required data length (datalen) must be at least 2 plus the parsed sense length (senselen).\nHistorically, the validation check only verified whether datalen < senselen, omitting the required 2-byte offset for the sense length prefix. Consequently, if a malicious or malformed target returns a SCSI Response where datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE), the bounds check improperly evaluates as valid. This allows the subsequent memcpy() operation to read from data + 2, extending up to two bytes past the boundaries of the received data buffer.\nThe payload behavior involves reading up to two bytes of stale conn->data contents residing immediately adjacent to the received packet buffer. These leaked bytes are then copied directly into the SCSI command's sense buffer (sc->sense_buffer). Because the sense buffer is ultimately returned to userspace via the standard SCSI interface, an unprivileged or privileged local application executing SCSI commands against the compromised target can retrieve these leaked memory fragments.\nThe attack flow proceeds as follows: First, an attacker establishes or intercepts an iSCSI session between the initiator and a target. Second, the attacker configures the target to respond to a SCSI command with a specially crafted SCSI Response data segment containing a mismatched data length relative to the sense length prefix. Third, the kernel's libiscsi subsystem processes the response via iscsi_scsi_cmd_rsp(), bypasses the flawed validation check, and reads past the end of the data buffer into stale connection memory. Fourth, the stale bytes are copied into the sense buffer. Finally, the userspace application retrieves the sense buffer, successfully extracting the leaked data."
}