CVE-2026-74557

The bug is in the SCSI sense data handling within the kernel's libiscsi implementation. When processing a response, the code validates that datalen >= senselen, then copies senselen bytes from the response buffer. But here's the critical detail: the sense data on the wire includes a 2-byte length prefix, and the memcpy operates on the data pointer offset by those 2 bytes. The bounds check validates against the logical sense length without accounting for this wire-format overhead. When datalen exactly equals senselen, the copy reads two bytes past the received data — landing in whatever stale data was previously stored in conn->data, the connection-scoped buffer. The narrow exploitable window (datalen == senselen, senselen <= 255) makes this look like a low-severity information disclosure, but that's the wrong framing. This vulnerability assumes a compromised storage target — an entity the kernel already trusts at session establishment. In that threat model, the attacker doesn't need to chain exploits or guess heap addresses. They've already passed the trust boundary. The 'narrow window' disappears because the malicious target controls the response format deterministically. The stale data also surfaces through userspace interfaces (SG_IO ioctls, uevent logs), creating an exfiltration path that enterprise monitoring pipelines will happily ingest and store. This is a recurring pattern in protocol parsers: developers validate against the declared length field but memcpy from the offset where the actual payload begins. The SCSI sense format's 2-byte wire-prefix isn't new — it's legacy protocol design from the 1980s that has been sitting in active kernel code since roughly 2009. The specific trigger condition (datalen exactly matching sense length with sense data present) is rare in normal operation, which is why it evaded detection for so long. Static analyzers like smatch and sparse can catch some buffer misuse, but the specific failure here is a semantic relationship between two non-adjacent statements — the check validates one offset, the memcpy uses another. That's exactly where static analysis historically struggles. What you should do: verify your storage array firmware trust model — if you assume compromised BMC/IPMI or firmware is possible, this vulnerability changes severity calculus significantly. Monitor for unexpected data in SCSI diagnostic responses, particularly from SG_IO ioctls. The fix is trivial (add 2 to the bounds check), but the deeper question is whether your threat model includes adversarial storage infrastructure — and if it doesn't, that's the gap this CVE exposes.

Reviewed through automated stages and approved by a human before publication.