From: Ibrahim Hashimov <security@auditcode.ai>
To: martin.petersen@oracle.com,
James.Bottomley@HansenPartnership.com, dlemoal@kernel.org
Cc: bvanassche@acm.org, shinichiro.kawasaki@wdc.com,
damien.lemoal@opensource.wdc.com, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH v4] scsi: scsi_debug: fix REPORT ZONES alloc_len underflow OOB write
Date: Sun, 12 Jul 2026 20:37:39 +0200 [thread overview]
Message-ID: <20260712183739.83915-1-security@auditcode.ai> (raw)
In-Reply-To: <20260710055755.53830-1-security@auditcode.ai>
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.
Fixes: 7db0e0c8190a ("scsi: scsi_debug: Fix buffer size of REPORT ZONES command")
Suggested-by: Damien Le Moal <dlemoal@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Ibrahim Hashimov <security@auditcode.ai>
Assisted-by: AuditCode-AI:2026.07
---
v4: clamp rep_max_zones to the device zone count (devip->nr_zones) so arr_len
cannot reach 0x100000000 and be truncated by kzalloc()'s 32-bit size_t on
32-bit platforms (which returns ZERO_SIZE_PTR and bypasses the NULL check),
as reported by sashiko-bot / Bart Van Assche on v3. This restores a bound
that pre-dated the loop refactor: the original REPORT ZONES code already
capped rep_max_zones at the device zone count. The clamp is additive and does
not change any report (the loop already stops at sdebug_capacity), so it only
bounds the allocation. Dropped Damien's v3 Reviewed-by since v4 adds a
functional line he has not reviewed; his ALIGN sizing is otherwise unchanged.
v3: https://lore.kernel.org/linux-scsi/20260710055755.53830-1-security@auditcode.ai/
drivers/scsi/scsi_debug.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 9d1c9c41d0f9..643051332132 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -5890,6 +5890,7 @@ static int resp_report_zones(struct scsi_cmnd *scp,
u32 alloc_len, rep_opts, rep_len;
bool partial;
u64 lba, zs_lba;
+ u64 arr_len;
u8 *arr = NULL, *desc;
u8 *cmd = scp->cmnd;
struct sdeb_zone_state *zsp = NULL;
@@ -5911,9 +5912,12 @@ static int resp_report_zones(struct scsi_cmnd *scp,
return check_condition_result;
}
- rep_max_zones = (alloc_len - 64) >> ilog2(RZONES_DESC_HD);
+ rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - RZONES_DESC_HD) >>
+ ilog2(RZONES_DESC_HD);
+ rep_max_zones = min_t(unsigned int, rep_max_zones, devip->nr_zones);
+ arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1);
- arr = kzalloc(alloc_len, GFP_ATOMIC | __GFP_NOWARN);
+ arr = kzalloc(arr_len, GFP_ATOMIC | __GFP_NOWARN);
if (!arr) {
mk_sense_buffer(scp, ILLEGAL_REQUEST, INSUFF_RES_ASC,
INSUFF_RES_ASCQ);
--
2.50.1 (Apple Git-155)
next prev parent reply other threads:[~2026-07-12 18:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 15:06 [PATCH] scsi: scsi_debug: fix REPORT ZONES alloc_len underflow OOB write Ibrahim Hashimov
2026-07-09 15:18 ` sashiko-bot
2026-07-09 19:48 ` [PATCH v2] " Ibrahim Hashimov
2026-07-10 0:58 ` Damien Le Moal
2026-07-10 5:57 ` [PATCH v3] " Ibrahim Hashimov
2026-07-10 6:03 ` Damien Le Moal
2026-07-10 6:05 ` sashiko-bot
2026-07-10 14:37 ` Bart Van Assche
2026-07-12 18:36 ` Ibrahim Hashimov
2026-07-12 18:37 ` Ibrahim Hashimov [this message]
2026-07-13 5:43 ` [PATCH v4] " Damien Le Moal
2026-07-13 17:12 ` Bart Van Assche
2026-07-10 5:59 ` [PATCH v2] " Ibrahim Hashimov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260712183739.83915-1-security@auditcode.ai \
--to=security@auditcode.ai \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bvanassche@acm.org \
--cc=damien.lemoal@opensource.wdc.com \
--cc=dlemoal@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=shinichiro.kawasaki@wdc.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.