From: Miquel Raynal <miquel.raynal@bootlin.com>
To: 林佳鹏 <ljp1205831794@gmail.com>
Cc: linux-mtd@lists.infradead.org, richard@nod.at, vigneshr@ti.com,
linux-kernel@vger.kernel.org, Aohan Mei <henrymei@tencent.com>,
TencentOS Corvus AI <corvus@tencent.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] mtd: inftl: validate MediaHeader partition geometry before allocating tables
Date: Thu, 03 Sep 2026 12:01:22 +0200 [thread overview]
Message-ID: <87y0di4psd.fsf@bootlin.com> (raw)
In-Reply-To: <906239c1-e78c-435c-954f-1198595d62b2@gmail.com> ("林佳鹏"'s message of "Thu, 3 Sep 2026 17:43:04 +0800")
On 03/09/2026 at 17:43:04 +08, 林佳鹏 <ljp1205831794@gmail.com> 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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2026-09-03 10:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 12:40 [PATCH] mtd: inftl: validate MediaHeader partition geometry before allocating tables henrymei
2026-09-03 8:04 ` Miquel Raynal
2026-09-03 9:43 ` 林佳鹏
2026-09-03 10:01 ` Miquel Raynal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y0di4psd.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=corvus@tencent.com \
--cc=henrymei@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=ljp1205831794@gmail.com \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.