Re: [PATCH v4] mtd: maps: add INT0800 firmware-flash map driver

[sashiko-bot]

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@xxxxxxxxx>

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@xxxxxxxxx?part=1