Re: [PATCH v3] scsi: scsi_debug: fix REPORT ZONES alloc_len underflow OOB write

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Integer truncation on 32-bit platforms leads to ZERO_SIZE_PTR out-of-bounds write and kernel panic
--

--- Patch [1]: [PATCH v3] scsi: scsi_debug: fix REPORT ZONES alloc_len underflow OOB write ---
commit 1e0d50f19491d296aa99221a898bda21deff84db
Author: Ibrahim Hashimov <security@auditcode.ai>

scsi: scsi_debug: fix REPORT ZONES alloc_len underflow OOB write

This commit fixes an out-of-bounds write in resp_report_zones() by sizing
the buffer to a whole number of 64-byte blocks that cover the requested
allocation length. It aligns the length and computes the buffer size in
64-bit to avoid a u32 wrap.

> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -5911,9 +5912,11 @@ 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);
> +	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);

[Severity: High]
Does this code cause a truncation and kernel panic on 32-bit systems?

If a user with raw IO access sends a REPORT ZONES SCSI command with an
alloc_len between 0xFFFFFFC1 and 0xFFFFFFFF, ALIGN() rounds it up to exactly
0x100000000 (4 GB) making arr_len exactly 0x100000000.

On 32-bit platforms, kzalloc() takes a 32-bit size_t, which silently
truncates 0x100000000 to 0. Calling kzalloc(0) returns ZERO_SIZE_PTR, which
bypasses the (!arr) NULL check.

>  	if (!arr) {
>  		mk_sense_buffer(scp, ILLEGAL_REQUEST, INSUFF_RES_ASC,
>  				INSUFF_RES_ASCQ);
>  		return check_condition_result;
>  	}
>  
>  	sdeb_meta_read_lock(sip);
>  
>  	desc = arr + 64;

Since arr is ZERO_SIZE_PTR (typically 0x10), desc becomes an unmapped
address (0x50).

[ ... ]

>  		if (nrz < rep_max_zones) {
>  			/* Fill zone descriptor */
>  			desc[0] = zsp->z_type;
>  			desc[1] = zsp->z_cond << 4;

The driver unconditionally dereferences the unmapped memory here, which
will trigger a deterministic kernel panic. 

Could we add a bounds check for alloc_len to ensure it doesn't exceed 32-bit
bounds or a reasonable maximum allocation size before passing it to kzalloc()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710055755.53830-1-security@auditcode.ai?part=1