ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes
Published Sep 11, 2026 · Updated Sep 11, 2026
In the Linux kernel, the following vulnerability has been resolved:
Summary
What happened
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes
ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller:
size = ata_format_dsm_trim_descr(scmd, trmax, block, n_block);
if (size != len) /* len == sdp->sector_size */
goto invalid_param_len;
ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with "Parameter list length error" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices.
The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page.
Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.
The record
- CVE
- CVE-2026-89586
- Published
- Sep 11, 2026
- Updated
- Sep 11, 2026
- Vendor
- The Linux Kernel Organization
- Product
- Linux
- Classifications
- Unavailable
- Attack vector
- Unavailable
- Privileges
- Unavailable
Timeline
How it unfolded
- Sep 11, 2026CVE publishedPublication date reported by the CVE source.
- Sep 11, 2026Record updatedLatest update available in the CVE record.
Exploitability
Present is not the same as exploitable
Compare your product and version with the public record. A matching version still requires validation against your environment.
Is a vulnerable build present?
Compare these published version ranges with your installed build and any vendor patches.
- Affected versionversion=4.9
- Affected versionversion=ef2d7392c4ece5c3cd12a6c7ca9366cd8f189aff <04e2befe25792f2e90097f284d7e86fc6bcfe928
- Affected versionversion=ef2d7392c4ece5c3cd12a6c7ca9366cd8f189aff <4a4268a0b0a595bd9534cf9c7fda93775a7d8a0d
- Affected versionversion=ef2d7392c4ece5c3cd12a6c7ca9366cd8f189aff <79cce911e623c0baa0fde307ce3a434e084b881a
- Affected versionversion=ef2d7392c4ece5c3cd12a6c7ca9366cd8f189aff <c2e3dccd6870659851eaa4c12ab16418b8e3040a
What conditions does exploitation require?
What is affected?
Published CVSS scores
No CVSS assessment is available in this record.
CVSS describes severity. EPSS estimates exploitation probability.
Attacks
What attackers are doing with it
Daily unique IPs observed by Shadowserver honeypots for known exploited vulnerabilities (KEVs). Missing observations do not establish an absence of attacks.
Weakness, pattern, technique
No sourced classifications are available.
Public exploit references
No public exploit references are available in this record.
Labels summarize the accepted research assessment. They do not indicate a test against your environment.
Technologies
Your stack
See the directory against your own environment.
Your stack
Check the software in your environment
Book a demo to see how Hinoki identifies affected software and validates exploitability in your environment.
Book a demo