Re: [PATCH] mtd: inftl: validate MediaHeader partition geometry before allocating tables

[林佳鹏 <ljp1205831794@gmail.com>]

Hi Miquèl,

On 02/09/2026, Miquel Raynal wrote:
> > is evaluated in unsigned 32-bit arithmetic.  With lastUnit < firstUnit
> 
> lastUnit < firstUnit? Did you even read that sentence?

I should have made the arithmetic explicit in the first place.
All three fields are __u32 (struct INFTLPartition), so with the
crafted header used in testing (firstUnit=7000, lastUnit=3,
virtualUnits=100):

    (3 - 7000 + 1) == 4294960300    /* u32 wrap */
    4294960300 < 100 == false    /* sanity check passes */

Execution then continues with nb_boot_blocks=7000 as the loop
bound against a kmalloc_array(lastUnit + 1 = 4, 2) = 8-byte
PUtable, and the boot-block marking loop writes ~14 KB past
the object.  Reproduced on v7.2-rc4 with a RAM-backed fake
DiskOnChip MTD device carrying that header:

    BUG: KASAN: slab-out-of-bounds in find_boot_record
    Write of size 2 ... 0 bytes to the right of allocated 8-byte region

That said, the reachability is admittedly narrow: this is a
mount-time path, so triggering requires root (device
registration) or physical control of the flash contents;
unprivileged users cannot reach it.  The intent is only
hardening of the MediaHeader parser, in the same spirit as
the sanity checks already in find_boot_record().

One fair point about v1: the new check runs on every partition
entry during the scan, while only the selected BDTL entry's
fields are actually used for the allocations.  If entries with
lastUnit < firstUnit can legitimately appear in other slots
on real media, I can respin to validate only the selected
partition (and drop the boot-record-unit check if preferred).

Happy to send a v2 along those lines if you think the
hardening is worthwhile; otherwise I will drop it.  Either
way, thanks for the time.

Thanks,
Aohan