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

[Miquel Raynal]

On 03/09/2026 at 17:43:04 +08, 林佳鹏 <ljp1205831794@xxxxxxxxx> wrote:

> 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.

Since this is a root-only exploit, I don't see the point in going
further. These "hardening" steps just darken the code from my opinion.

Thanks,
Miquèl