From: sashiko-bot@kernel.org
To: "Stephen Bancroft" <stevereaver@gmail.com>,
linux-mtd@lists.infradead.org
Cc: "Richard Weinberger" <richard@nod.at>,
linux-kernel@vger.kernel.org,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>
Subject: Re: [PATCH v4] mtd: maps: add INT0800 firmware-flash map driver
Date: Wed, 23 Sep 2026 09:41:44 +0000 [thread overview]
Message-ID: <20260923094144.E723B1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260923092626.873202-1-stevereaver@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtd: maps: UAF of mtd_info and I/O memory on device unregistration
--
commit ad3016fe3893b23f61acf9f96913ff51726ac3a0
Author: Stephen Bancroft <stevereaver@gmail.com>
mtd: maps: add INT0800 firmware-flash map driver
Add a read-only mapping driver that binds the ACPI INT0800 "Intel
82802 firmware hub" device and exposes the system firmware flash as an
MTD ROM device.
> diff --git a/drivers/mtd/maps/int0800.c b/drivers/mtd/maps/int0800.c
> new file mode 100644
> index 0000000000000..c5f108aa34797
> --- /dev/null
> +++ b/drivers/mtd/maps/int0800.c
[ ... ]
> +static void int0800_remove(struct platform_device *pdev)
> +{
> + struct int0800 *fw = platform_get_drvdata(pdev);
> +
> + mtd_device_unregister(fw->mtd);
> + map_destroy(fw->mtd);
[Severity: High]
Does this teardown path force a use-after-free if the device is removed
while a file descriptor is open?
While the driver sets .suppress_bind_attrs = true to prevent manual sysfs
unbinds, the driver core can still invoke remove() when the underlying
device is unregistered. This can happen if root unbinds the parent bridge
in sysfs, or via ACPI SSDT unloading.
If int0800_remove() is invoked while userspace holds an open file
descriptor, mtd_device_unregister() puts the kref but does not release
the struct device because the character device retains an active reference.
Unconditionally calling map_destroy(fw->mtd) then frees the mtd_info
structure. Could subsequent /dev/mtd0 reads or sysfs accesses dereference
this freed memory and access unmapped devm I/O memory?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260923092626.873202-1-stevereaver@gmail.com?part=1
next prev parent reply other threads:[~2026-09-23 9:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <V2-MESSAGE-ID>
2026-09-21 2:14 ` [PATCH v3] " Stephen Bancroft
2026-09-21 2:30 ` sashiko-bot
2026-09-23 9:26 ` [PATCH v4] " Stephen Bancroft
2026-09-23 9:41 ` sashiko-bot [this message]
2026-09-23 11:57 ` Steve Reaver
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=20260923094144.E723B1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=sashiko-reviews@lists.linux.dev \
--cc=stevereaver@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®