Re: [PATCH] mtd: inftl: validate MediaHeader partition geometry before allocating tables
From: 林佳鹏
Date: Thu Sep 03 2026 - 05:49:32 EST
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