HIGH Introduced in 4.9
libata DsmTrim Validation
CVE-2026-89586
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
KernelScan AI3.3LOW
01Description
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.
02KernelScan AI Analysis
Risk summary
On ATA devices with logical sector sizes larger than 2048 bytes (e.g. 4Kn drives), the DSM TRIM translation path always fails because the descriptor size is compared against the logical sector size rather than the fixed 512-byte DSM page size. Every TRIM or discard attempt on such devices is rejected and produces a kernel warning splat, rendering discard functionality completely non-functional and flooding kernel logs. This is a local functional/availability issue with no memory corruption or privilege escalation impact.
Vulnerability analysis
When the kernel translates a SCSI WRITE SAME with UNMAP into an ATA DATA SET MANAGEMENT TRIM command, it builds a trim descriptor and compares the number of bytes written against the device's logical sector size. The descriptor builder internally clamps its output to a 2048-byte staging buffer, so on devices with 4096-byte (4Kn) logical sectors the returned size can never match the expected sector size. The comparison always fails, every TRIM is rejected with a parameter-length error, and a kernel warning is emitted on each attempt. The fix changes the code to always emit exactly one 512-byte DSM trim page regardless of logical sector size, compares against that fixed size, and transfers only the 512-byte page. This is reachable locally by any process that causes a discard request on a 4Kn ATA device whose filesystem is mounted with the discard option, or when an administrator runs fstrim; no special privileges are needed to trigger the path once discard is enabled, though initial configuration requires root.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 4.9 | 6.12.109 | 04e2befe2579 |
| 5.10 | 4.9 | 5.10.270 | 07975b8daa3b |
| 6.1 | 4.9 | 6.1.188 | 07baa310ea32 |
| 5.15 | 4.9 | 5.15.221 | b7b5ab2df325 |
| 6.6 | 4.9 | 6.6.157 | 977554ed91b5 |
| 6.18 | 4.9 | 6.18.50 | c2e3dccd6870 |
| 7.2 | 4.9 | 7.2.4 | 4a4268a0b0a5 |
| mainline | 4.9 | 7.3-rc1 | 79cce911e623 |
| cip/6.12 | 4.9 | 6.12.111-cip32 | 04e2befe2579 |