CVE-2026-89515

What it actually does

The Linux SCSI core fails to initialize DMA padding bytes added to the last scatter-gather entry in scsi_alloc_sgtables() when an I/O buffer is unaligned. Those pad_len bytes remain uninitialized kernel heap memory and are subsequently DMA-mapped (for example via ata_qc_issue / dma_map_sg_attrs). The result is a kernel information disclosure: leftover heap contents can be exposed to a SCSI/ATA device or otherwise observed through DMA of the padded region. The issue is a memory-safety defect (uninit-value), not a remote code-execution primitive.

Why it matters to the business

Operational risk is limited and primarily confidentiality-oriented: a local process that can issue SCSI I/O may leak fragments of kernel memory, which could include secrets if they happen to reside in the uninitialized padding. There is no CISA KEV listing, no known ransomware use, exploit maturity is None, and EPSS is very low and flat (~0.0018 over 30 days). About one month after publication there is still no evidence of in-the-wild exploitation. Impact is confined to Linux hosts that exercise the SCSI core with padded scatterlists (storage, optical, and passthrough devices). Absence of a named fixed-version list means organizations must track vendor or distro kernel updates rather than a single package bump.

How an attack unfolds

An attacker with local access to a SCSI-capable block or generic SCSI device crafts I/O (commonly via SG_IO / scsi ioctl) whose user buffer mapping produces an unaligned last scatterlist element. The kernel allocates pages for that mapping, then scsi_alloc_sgtables() extends the last entry by pad_len without zeroing the extra bytes. When the command is queued, the DMA layer maps the entire padded region, including uninitialized heap. Sensitive leftover kernel data can then be read by cooperating firmware, observed on a subsequent DMA-visible transfer, or inferred through device-assisted inspection. No remote unauthenticated path is described; exploitation depends on local ioctl/block I/O to SCSI, and no named threat actors or campaigns are associated with this CVE.

How to fix it

Apply a Linux kernel update that includes the SCSI core fix for scsi_alloc_sgtables(): extend last_sg->length by pad_len and zero the padding with sg_zero_buffer() (which correctly handles multi-page sg entries and padding that crosses a page boundary). Because no canonical upstream version list was supplied with this record, take the newest stable or LTS kernel from your distro/vendor that explicitly references this SCSI DMA-padding initialization fix, then reboot into the patched kernel. If immediate patching is not possible, restrict who can open SCSI-generic, optical, and passthrough devices (tighten udev/group permissions, drop unneeded CAP_SYS_RAWIO / CAP_SYS_ADMIN, and avoid exposing /dev/sg* or equivalent to untrusted users or containers). Do not rely on configuration workarounds as a complete fix; uninitialized DMA padding is only correctly handled in patched kernels.

How to confirm the fix worked

Confirm the running kernel changelog or source contains the scsi_alloc_sgtables() change that zeros pad_len via sg_zero_buffer() after extending the last scatterlist entry. On packaged distros, verify the installed kernel package is at or beyond the vendor advisory that maps to this CVE, then reboot and check uname -r. For exposure detection, inventory hosts that load SCSI/ATA/libata and that allow non-root or container access to sg, sr, or SCSI passthrough nodes. Optional: on a lab kernel built with KMSAN, replay unaligned SG_IO against a SCSI device and confirm the former uninit-value report in __dma_map_sg_attrs / dma_map_sg_attrs no longer fires.

Typical attack path

1. Obtain local execution on a Linux host with access to a SCSI/ATA/optical or SCSI-generic device node
2. Open the target block or sg device and issue ioctl-based SCSI I/O (for example SG_IO) with an unaligned user buffer so the request mapping creates a short last scatterlist entry
3. Trigger SCSI command submission so scsi_alloc_sgtables() adds uninitialized DMA padding and the padded SGL is DMA-mapped
4. Recover leftover kernel heap contents from the padded DMA region via the device or a follow-on data path
5. Use any leaked kernel material to inform further local attacks (credential/token hunting, KASLR-adjacent data, or heap layout insight)

How to detect it

Post-exploitation evidence for this class of uninitialized DMA padding leak is sparse: there is no malware implant, no network C2, and no stable user-space artifact. Hunt for local preconditions and suspicious SCSI passthrough rather than a unique payload. Review audit logs (auditd/eBPF) for untrusted UIDs opening /dev/sg*, /dev/sr*, or other SCSI-generic nodes and issuing SG_IO / BLK* ioctls around the time of concern. Kernel logs may show related SCSI/ATA command failures but will not name this CVE. On debug or KMSAN/KASAN kernels, search for historic uninit-value reports in __dma_map_sg_attrs, dma_map_sg_attrs, ata_qc_issue, scsi_queue_rq, or scsi_alloc_sgtables. Compare running kernel versions against the patched SCSI-core fix; unpatched hosts with open SCSI ioctl access are the exposure set. No APT or ransomware telemetry is associated with this identifier.

What your security team should do

• Patch and reboot Linux kernels to a build that zeros SCSI DMA padding in scsi_alloc_sgtables(); treat distro advisory mapping as the source of truth for exact versions
• Prioritize hosts that expose SCSI-generic, optical, or passthrough devices to untrusted users, CI runners, or containers, even though EPSS is low and the CVE is not in KEV
• Restrict device-node permissions and drop raw-I/O capabilities for workloads that do not need SCSI ioctls
• Track vendor kernel streams until this fix is confirmed present; re-scan after the next kernel rollout
• Do not allocate emergency incident resources solely on EPSS or KEV for this item; keep it in standard patch SLAs unless local SCSI passthrough is widely granted