Re: [PATCH 1/2] mtd: mtd_intel_dg: add survivability partition

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unsigned integer underflow in bounds checks allows out-of-bounds hardware memory accesses when survivability mode is enabled.
--

--- Patch [1]: [PATCH 1/2] mtd: mtd_intel_dg: add survivability partition ---
commit 9f27e4e8d4c741d1106f13ea61bac2daf3838cad
Author: Alexander Usyskin <alexander.usyskin@intel.com>

mtd: mtd_intel_dg: add survivability partition

This commit adds an option to expose a fixed-sized survivability partition
starting from the beginning of storage. This can be used when the firmware
or hardware detects a failure involving a corrupted partition table,
allowing a full storage re-write.

> diff --git a/drivers/mtd/devices/mtd_intel_dg.c b/drivers/mtd/devices/mtd_intel_dg.c
> index f2fa8f68d1905..d11ddc687c4ac 100644
> --- a/drivers/mtd/devices/mtd_intel_dg.c
> +++ b/drivers/mtd/devices/mtd_intel_dg.c
[ ... ]
> @@ -205,6 +206,13 @@ static unsigned int idg_nvm_get_region(const struct intel_dg_nvm *nvm, loff_t fr
>  {
>  	unsigned int i;
>  
> +	/*
> +	 * When survivability region is enabled it positioned on index 0 and has region_id = 0
> +	 * Region 0 is special, via this region whole device memory can be accessed.
> +	 */
> +	if (nvm->survivability_enabled)
> +		return 0;
> +

[Severity: High]
Does this unconditional return of 0 create an underflow risk in the read,
write, and erase paths?

When survivability is enabled, idg_nvm_get_region() will always return
index 0. If nvm->size was inflated during initialization by parsing limits
from a corrupted partition table, a request could arrive with an offset
larger than nvm->regions[0].size.

In drivers/mtd/devices/mtd_intel_dg.c:intel_dg_mtd_read(), the bounds check
subtracts the offset from the region size:

    idx = idg_nvm_get_region(nvm, from);
    
    if (len > nvm->regions[idx].size - from)
        len = nvm->regions[idx].size - from;

If the from offset exceeds nvm->regions[0].size, the unsigned subtraction
will underflow, resulting in a very large value. This bypasses the length
truncation and allows out-of-bounds hardware memory accesses.

Could the same underflow occur in the bounds checks in intel_dg_mtd_write()
and intel_dg_mtd_erase()?

>  	for (i = 0; i < nvm->nregions; i++) {
>  		if ((nvm->regions[i].offset + nvm->regions[i].size - 1) >= from &&

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-cri_surviv-v1-0-61763a6f1076@intel.com?part=1