Re: [PATCH 3/4] scsi: pm8001: free CCB resources on allocation failure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Out-of-bounds array accesses and integer underflow due to unvalidated device-supplied `max_out_io` limit.
--

commit 54b6fce7eebff69bdb11ab411c836b69e2bfd3d1
Author: Peng Hao <flyingpenghao@gmail.com>

scsi: pm8001: free CCB resources on allocation failure

This commit adds a common CCB cleanup helper to avoid leaking buffers
when CCB PRD allocation fails. It also moves device teardown into
pm8001_free() and removes duplicate teardown logic from the remove path.

> diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c
> index 20b02e63be8c9..a747de9a3ca0a 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c

[ ... ]

> @@ -1285,8 +1313,8 @@ static int pm8001_init_ccb_tag(struct pm8001_hba_info *pm8001_ha)
>  	return 0;
>  
>  err_out_noccb:
> -	kfree(pm8001_ha->devices);
>  err_out:
> +	pm8001_free_ccb(pm8001_ha);
>  	return -ENOMEM;
>  }

[Severity: High]
This is a pre-existing issue, but does deriving ccb_count directly from the
untrusted device configuration without a safe lower bound cause integer
underflow and out-of-bounds accesses?

Earlier in pm8001_init_ccb_tag(), the driver reads max_out_io directly
from the device's MMIO:

	max_out_io = pm8001_ha->main_cfg_tbl.pm80xx_tbl.max_out_io;
	ccb_count = min_t(int, PM8001_MAX_CCB, max_out_io);

	shost->can_queue = ccb_count - PM8001_RESERVE_SLOT;

If the device provides a max_out_io value smaller than PM8001_RESERVE_SLOT,
will shost->can_queue underflow to a negative value, potentially corrupting
block layer limits?

Furthermore, since the ccb_info array is allocated based on this restricted
ccb_count, could this cause out-of-bounds memory accesses during driver
operation? For example, in pm8001_hwi.c:pm8001_work_fn(), the code
unconditionally iterates up to PM8001_MAX_CCB instead of the dynamically
allocated ccb_count:

	for (i = 0; ccb = NULL, i < PM8001_MAX_CCB; i++) {
		ccb = &pm8001_ha->ccb_info[i];
		if ((ccb->ccb_tag != PM8001_INVALID_TAG) &&
		    (ccb->task == t))
			break;
	}

Could an untrusted or compromised PCIe device trigger a kernel panic by
providing a small max_out_io value, causing these loops to iterate past
the bounds of pm8001_ha->ccb_info?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911091011.94676-1-flyingpeng@tencent.com?part=3