scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.15.217, 5.11, 6.1.183, 6.6.151, 6.12.103, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From ebacb44cb2042b90951140eda806bedad23ef554 · fixed in 7b615fc139e35c81077046df44725c532f7e2404; From 7db0e0c8190a086ef92ce5bb960836cde49540aa · fixed in 5d3e1d006bbb543259f9e31824caadbfff6a5465; From 7db0e0c8190a086ef92ce5bb960836cde49540aa · fixed in 49e5b25a0b74dbac595f122e5608fdce2918cc4e; From 7db0e0c8190a086ef92ce5bb960836cde49540aa · fixed in 495058429ca55ab7fcc21977b63b92907ad68066; From 7db0e0c8190a086ef92ce5bb960836cde49540aa · fixed in 2047ed09bf13453b7d6f9431b112ec07984dd69b; From 7db0e0c8190a086ef92ce5bb960836cde49540aa · fixed in d6e6da6bc3b53231fac77ffab428da8173ee729c; From 7db0e0c8190a086ef92ce5bb960836cde49540aa · fixed in 93dde0bf2f39a0f9f57fd610aa3201ce5b753433; From 5.15.8 · fixed in 5.15.217; From 5.10.85 · fixed in 5.11
- Linux Linux
5.16
- KernelLinux
fixed in 5.15.217; From 5.16.0 · fixed in 6.1.183; fixed in 6.6.151; From 6.2.0 · fixed in 6.12.103; From 6.7.0 · fixed in 6.18.44; From 6.13.0 · fixed in 7.1.8
References 7
git.kernel.org
- stable/c/7b615fc139e35c81077046df44725c532f7e2404
- stable/c/5d3e1d006bbb543259f9e31824caadbfff6a5465
- stable/c/49e5b25a0b74dbac595f122e5608fdce2918cc4e
- stable/c/495058429ca55ab7fcc21977b63b92907ad68066
- stable/c/2047ed09bf13453b7d6f9431b112ec07984dd69b
- stable/c/d6e6da6bc3b53231fac77ffab428da8173ee729c
- stable/c/93dde0bf2f39a0f9f57fd610aa3201ce5b753433