CVE-2026-89515 json
scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()
published 2mo ago modified 23d ago also EUVD-2026-76421
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 7%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()
During fuzz testing, the following issue was discovered:
BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw_queue+0x4bb/0x7e0 blk_mq_sched_insert_request+0x2a7/0x4c0 blk_execute_rq+0x497/0x8a0 sg_io+0xbe0/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Uninit was created at: __alloc_pages+0x5c0/0xc80 alloc_pages+0xe0e/0x1050 blk_rq_map_user_iov+0x2b77/0x6100 blk_rq_map_user_io+0x2fa/0x4d0 sg_io+0xad6/0xe20 scsi_ioctl+0x2b36/0x3c60 sr_block_ioctl+0x319/0x440 blkdev_ioctl+0x80f/0xd70 __se_sys_ioctl+0x219/0x420 __x64_sys_ioctl+0x93/0xe0 x64_sys_call+0x1d6c/0x3ad0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Bytes 14-15 of 16 are uninitialized Memory access of size 16 starts at ffff88800cbdb000
When processing the last unaligned element of the scatterlist, it is supplemented with missing bytes in the amount of pad_len. These bytes remain uninitialized, which leads to a problem.
Extend last_sg->length by pad_len first, then use sg_zero_buffer() to zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally, which correctly handles sg entries spanning multiple pages and padding that crosses a page boundary.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Patch / fix
- Linux Linux 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50, 7.2.4, 7.3
- linux Debian 12 6.1.190-1
- linux Debian 13 6.12.111-1
- linux Debian 14 7.2.6-1
- linux-6.12 Debian 12 6.12.111-1~deb12u1
debian advisories DEBIAN-CVE-2026-89515
- linux Ubuntu 22.04 LTS 5.15.0-202.212
- linux Ubuntu 24.04 LTS 6.8.0-149.149
- linux Ubuntu 26.04 LTS 7.0.0-42.42
- linux-aws Ubuntu 22.04 LTS 5.15.0-1119.126
- linux-aws Ubuntu 24.04 LTS 6.8.0-1069.74
- linux-aws Ubuntu 26.04 LTS 7.0.0-1016.17
- linux-gcp Ubuntu 22.04 LTS 5.15.0-1120.130
- linux-gcp Ubuntu 24.04 LTS 6.8.0-1073.81
ubuntu advisories UBUNTU-CVE-2026-89515
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-source openSUSE Tumbleweed 7.2.7-1.1
opensuse advisories openSUSE-SU-2026:11880-1
- kernel Azure Linux 3.0 6.6.157.1-1
azure linux advisories AZL-100319
Azure Linux vulnerability data, Copyright (c) Microsoft Corporation, from https://github.com/microsoft/AzureLinuxVulnerabilityData via OSV, under the MIT licence; changed: normalised to fixed package versions per release. MIT
- git.kernel.org/stable/c/1aa6df61cef1f47f503c3ccf60d08c4dd931fdc1 commit
- git.kernel.org/stable/c/6da140ebdfdd6aa3773945f2c0ebba01d2ef33d8 commit
- git.kernel.org/stable/c/fd2cbe08c6ccba7fc1ddb830653a93bb7e2d833c commit
- git.kernel.org/stable/c/28ed5343666ff424ce5e248fa1c5a402303b4aff commit
- git.kernel.org/stable/c/a4353ec7742bdf87dcdde5875270feb3a1982a51 commit
- git.kernel.org/stable/c/e7143c3f4e5c0a7986733c6f27009274bf6c4264 commit
- git.kernel.org/stable/c/6fd1cce5018fdcc8d928e00a6a1dd2997d5b9409 commit
- git.kernel.org/stable/c/626147717bea776b61ed3631d2c26283760c4cc4 commit
Is CVE-2026-89515 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-89515 updated cvss 5.5
kernel: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 moreaffected: workaround, no fix planned “Out of support scope”
-
Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8, openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9affected: workaround, no fix available “Fix deferred”
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.18% chance of exploitation in the next 30 days, higher than 7% of all scored CVEs (FIRST EPSS, 2026-11-11).
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/1aa6df61cef1f47f503c3ccf60d08c4dd931fdc1
- git.kernel.org /stable/c/6da140ebdfdd6aa3773945f2c0ebba01d2ef33d8
- git.kernel.org /stable/c/fd2cbe08c6ccba7fc1ddb830653a93bb7e2d833c
- git.kernel.org /stable/c/28ed5343666ff424ce5e248fa1c5a402303b4aff
- git.kernel.org /stable/c/a4353ec7742bdf87dcdde5875270feb3a1982a51
- git.kernel.org /stable/c/e7143c3f4e5c0a7986733c6f27009274bf6c4264
- git.kernel.org /stable/c/6fd1cce5018fdcc8d928e00a6a1dd2997d5b9409
- git.kernel.org /stable/c/626147717bea776b61ed3631d2c26283760c4cc4
Sources
- CVE List CVE-2026-89515
- NVD CVE-2026-89515
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.