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 <[email protected]> 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/[email protected]?part=1
