Improper Handling of Length Parameter Inconsistency Affecting python3-perf package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-PYTHON3PERF-19833522
- published16 Sept 2026
- disclosed11 Sept 2026
Introduced: 11 Sep 2026
NewCVE-2026-89586 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 python3-perf.
NVD Description
Note: Versions mentioned in the description apply only to the upstream python3-perf package and not the python3-perf package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
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.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2532420
- https://access.redhat.com/security/cve/CVE-2026-89586
- https://git.kernel.org/stable/c/04e2befe25792f2e90097f284d7e86fc6bcfe928
- https://git.kernel.org/stable/c/4a4268a0b0a595bd9534cf9c7fda93775a7d8a0d
- https://git.kernel.org/stable/c/79cce911e623c0baa0fde307ce3a434e084b881a
- https://git.kernel.org/stable/c/c2e3dccd6870659851eaa4c12ab16418b8e3040a
- https://git.kernel.org/stable/c/07975b8daa3b0ab3cbc02cc48ea7bc48fadcec53
- https://git.kernel.org/stable/c/07baa310ea3224a7044b1ca84796bb37a235af1f
- https://git.kernel.org/stable/c/977554ed91b54075fbc0bac536316b4841ef6258
- https://git.kernel.org/stable/c/b7b5ab2df325ffbbad7ca2debaa071e024d68cb5