{"id":"CVE-2026-89586","summary":"ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes\n\nata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the\nUNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command.  The TRIM\ndescriptor is built by ata_format_dsm_trim_descr() into the 2048-byte\nata_scsi_rbuf staging buffer, and the number of bytes copied is compared\nagainst the logical sector size by the caller:\n\n\tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block);\n\tif (size != len)\t\t/* len == sdp-\u003esector_size */\n\t\tgoto invalid_param_len;\n\nata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE\n(2048).  On a device whose logical sector size exceeds that (e.g. a 4Kn\ndevice, where sector_size == 4096) the function can never return more than\n2048, while the caller expects it to return sector_size.  The comparison\ntherefore always fails, so every TRIM is rejected with \"Parameter list\nlength error\" and WARN_ON() splats on each attempt.  TRIM / discard is\nthus completely broken on such devices.\n\nThe descriptor was incorrectly sized from the logical sector size.  A DSM\nTRIM payload is a list of 512-byte pages, each holding up to\nATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical\nsector size.  The Block Limits VPD page already advertises a single such\npage as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical\nblocks), so the block layer never sends a request that needs more than one\npage.\n\nEmit exactly one 512-byte page, independent of the logical sector size,\nand transfer only that page (COUNT == 1).  For a 512-byte-sector device\nthis is unchanged; devices with larger logical sectors now work instead of\nfailing every TRIM.","modified":"2026-09-13T03:47:19.416793361Z","published":"2026-09-11T19:44:51.322Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89586.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/04e2befe25792f2e90097f284d7e86fc6bcfe928"},{"type":"WEB","url":"https://git.kernel.org/stable/c/4a4268a0b0a595bd9534cf9c7fda93775a7d8a0d"},{"type":"WEB","url":"https://git.kernel.org/stable/c/79cce911e623c0baa0fde307ce3a434e084b881a"},{"type":"WEB","url":"https://git.kernel.org/stable/c/c2e3dccd6870659851eaa4c12ab16418b8e3040a"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89586.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89586"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"ef2d7392c4ece5c3cd12a6c7ca9366cd8f189aff"},{"fixed":"04e2befe25792f2e90097f284d7e86fc6bcfe928"},{"fixed":"c2e3dccd6870659851eaa4c12ab16418b8e3040a"},{"fixed":"4a4268a0b0a595bd9534cf9c7fda93775a7d8a0d"},{"fixed":"79cce911e623c0baa0fde307ce3a434e084b881a"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-89586.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.9.0"},{"fixed":"6.12.109"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.50"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.2.4"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-89586.json"}}],"schema_version":"1.9.0"}