CVE-2026-89586

What it actually does

In the Linux kernel libata SCSI translation path, ata_scsi_write_same_xlat() converts SCSI WRITE SAME with UNMAP into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built into a 2048-byte staging buffer and the copied length is compared to the device logical sector size. On devices whose logical sector size exceeds 2048 bytes (for example 4Kn/4096-byte sectors) the function can never return a matching length, so every TRIM is rejected as an invalid parameter-list length and a WARN_ON fires. Discard/TRIM is therefore completely non-functional on those devices. Repeated attempts flood kernel logs; if panic_on_warn is enabled the host can panic. Assigned scoring also reflects limited confidentiality impact (typically warning/stack-trace leakage), with no integrity impact.

Why it matters to the business

Space reclamation (discard/TRIM) fails on affected large-sector ATA/SATA devices, which can stall thin provisioning, SSD garbage collection, and capacity management and may degrade storage performance over time. Availability risk is kernel log storms and, on hosts that panic on warnings, a full outage. The flaw is not in CISA KEV, has no public exploit maturity, and a low, flat EPSS (~0.006 over 30 days), so opportunistic mass exploitation is unlikely; the operational urgency is broken discard on 4Kn hardware and warning noise that can hide other faults. The issue has been public for about 37 days.

How an attack unfolds

An actor who can submit SCSI WRITE SAME UNMAP or equivalent block-layer discard I/O to an affected kernel—locally or over a storage fabric that reaches libata SCSI translation—targets a device with logical sector size greater than 2048 bytes. Each TRIM hits the length mismatch, is rejected with a parameter-list length error, and triggers WARN_ON in the ATA SCSI path. That denies discard operations, can exhaust logging, and can crash the host if warnings are treated as fatal. This is a fail-closed translation bug, not a memory-corruption primitive. No named threat actors, ransomware use, or public exploit activity are associated with this issue.

How to fix it

Apply the upstream libata-scsi fix that emits exactly one 512-byte DSM TRIM page (COUNT == 1), independent of logical sector size, instead of sizing the descriptor from the sector size. Deploy a distribution or vendor kernel that includes this change. No per-package fixed versions were supplied with this advisory—track kernel changelogs for the DSM TRIM / libata-scsi sector-size fix. There is no sysctl that restores TRIM on 4Kn devices; do not use panic_on_warn as a substitute for patching. Until patched, treat discard as unavailable on large-sector ATA devices and avoid depending on fstrim/thin reclaim for those volumes.

How to confirm the fix worked

Confirm the running kernel contains the libata DSM TRIM change (single 512-byte page, COUNT == 1). On a 4Kn ATA device, run discard/fstrim/WRITE SAME UNMAP and verify success with no SCSI parameter-list length error and no WARN_ON from ata_scsi_write_same_xlat in dmesg or the journal. On 512-byte-sector devices, confirm TRIM behavior is unchanged. After upgrade, grep kernel logs for residual libata-scsi warnings and verify logical sector size via standard block-layer sysfs.

Typical attack path

1. Find a Linux host using libata SCSI translation with an ATA device whose logical sector size is larger than 2048 bytes (for example 4Kn).
2. Obtain a path that can issue WRITE SAME UNMAP or discard I/O to that device (local process, container with access to the block device, or a network SCSI/iSCSI-style path).
3. Send TRIM/UNMAP requests so ata_scsi_write_same_xlat() builds a DSM TRIM descriptor.
4. The kernel rejects every TRIM, logs parameter-list length errors, and emits WARN_ON; repeated requests amplify log volume or panic the host if panic_on_warn is set.
5. Discard remains unavailable; in the panic case the entire node is taken down.

How to detect it

This bug fails closed (TRIM rejected) rather than dropping a payload, so evidence of abuse or accidental triggering is kernel warnings and failed discard I/O, not malware artifacts. Search dmesg, journalctl -k, /var/log/kern.log, and crash dumps for WARN_ON in drivers/ata/libata-scsi.c, especially ata_scsi_write_same_xlat / ata_format_dsm_trim_descr, and SCSI sense text indicating parameter list length error on WRITE SAME/UNMAP. Correlate with fstrim, blkdiscard, guest TRIM, or iSCSI WRITE SAME activity and with ATA devices whose logical sector size exceeds 2048 bytes. No named APT or ransomware telemetry is tied to this CVE. Lack of warnings only means TRIM was not attempted or the device was 512-byte sector—not that the vulnerable code was absent.

• ata_scsi_write_same_xlat
• ata_format_dsm_trim_descr
• drivers/ata/libata-scsi.c
• Parameter list length error
• invalid_param_len
• WRITE SAME
• DSM TRIM
• WARN_ON

What your security team should do

• Patch Linux kernels on ATA/SATA hosts first, especially 4Kn or other large-sector devices, even though this CVE is not in KEV and EPSS remains low.
• Hunt kernel logs for libata-scsi WARN_ON and WRITE SAME/TRIM parameter-list length errors to find exposed or noisy hosts.
• Ensure panic_on_warn is not enabled on production systems unless there is a deliberate hardening exception.
• Inventory block devices with logical sector size greater than 2048 bytes and assume discard is broken there until the kernel is upgraded.
• Track vendor kernel advisories for the exact libata-scsi TRIM fix; re-validate fstrim/discard after rollout.
• Keep watching KEV/EPSS; current exploit maturity is none and no ransomware mapping is reported.