Answer in brief
CVE-2026-74470 records a High severity (CVSS 7.8) vulnerability in scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=7db0e0c8190a086ef92ce5bb960836cde49540aa <49e5b25a0b74dbac595f122e5608fdce2918cc4e || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <495058429ca55ab7fcc21977b63b92907ad68066 || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <2047ed09bf13453b7d6f9431b112ec07984dd69b || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <d6e6da6bc3b53231fac77ffab428da8173ee729c || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <93dde0bf2f39a0f9f57fd610aa3201ce5b753433 || c4d2d7c935a4ad20e8e726ca10499cefe4537103 || ebacb44cb2042b90951140eda806bedad23ef554 || >=5.10.85 <5.11 || >=5.15.8 <5.16 | 49e5b25a0b74dbac595f122e5608fdce2918cc4e, 495058429ca55ab7fcc21977b63b92907ad68066, 2047ed09bf13453b7d6f9431b112ec07984dd69b, d6e6da6bc3b53231fac77ffab428da8173ee729c, 93dde0bf2f39a0f9f57fd610aa3201ce5b753433, 5.11, 5.16 |
| Linux/Linuxgeneric | 5.16 | Not reported |
| Linux/Linuxgeneric | >=7db0e0c8190a086ef92ce5bb960836cde49540aa <5d3e1d006bbb543259f9e31824caadbfff6a5465 || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <49e5b25a0b74dbac595f122e5608fdce2918cc4e || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <495058429ca55ab7fcc21977b63b92907ad68066 || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <2047ed09bf13453b7d6f9431b112ec07984dd69b || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <d6e6da6bc3b53231fac77ffab428da8173ee729c || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <93dde0bf2f39a0f9f57fd610aa3201ce5b753433 || c4d2d7c935a4ad20e8e726ca10499cefe4537103 || ebacb44cb2042b90951140eda806bedad23ef554 || >=5.10.85 <5.11 || >=5.15.8 <5.16 | 5d3e1d006bbb543259f9e31824caadbfff6a5465, 49e5b25a0b74dbac595f122e5608fdce2918cc4e, 495058429ca55ab7fcc21977b63b92907ad68066, 2047ed09bf13453b7d6f9431b112ec07984dd69b, d6e6da6bc3b53231fac77ffab428da8173ee729c, 93dde0bf2f39a0f9f57fd610aa3201ce5b753433, 5.11, 5.16 |
| Linux/Linuxgeneric | >=ebacb44cb2042b90951140eda806bedad23ef554 <7b615fc139e35c81077046df44725c532f7e2404 || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <5d3e1d006bbb543259f9e31824caadbfff6a5465 || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <49e5b25a0b74dbac595f122e5608fdce2918cc4e || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <495058429ca55ab7fcc21977b63b92907ad68066 || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <2047ed09bf13453b7d6f9431b112ec07984dd69b || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <d6e6da6bc3b53231fac77ffab428da8173ee729c || >=7db0e0c8190a086ef92ce5bb960836cde49540aa <93dde0bf2f39a0f9f57fd610aa3201ce5b753433 || c4d2d7c935a4ad20e8e726ca10499cefe4537103 || >=5.15.8 <5.15.217 || >=5.10.85 <5.11 | 7b615fc139e35c81077046df44725c532f7e2404, 5d3e1d006bbb543259f9e31824caadbfff6a5465, 49e5b25a0b74dbac595f122e5608fdce2918cc4e, 495058429ca55ab7fcc21977b63b92907ad68066, 2047ed09bf13453b7d6f9431b112ec07984dd69b, d6e6da6bc3b53231fac77ffab428da8173ee729c, 93dde0bf2f39a0f9f57fd610aa3201ce5b753433, 5.15.217, 5.11 |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.