* [PATCH v3] mtd: maps: add INT0800 firmware-flash map driver [not found] <V2-MESSAGE-ID> @ 2026-09-21 2:14 ` Stephen Bancroft 2026-09-21 2:30 ` sashiko-bot 2026-09-23 9:26 ` [PATCH v4] " Stephen Bancroft 0 siblings, 2 replies; 6+ messages in thread From: Stephen Bancroft @ 2026-09-21 2:14 UTC (permalink / raw) To: linux-mtd Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, linux-kernel, Stephen Bancroft 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. On x86 machines the boot flash is decoded into the physical address space below 4 GB, so a plain ioremap() of the declared resource window is sufficient for reads - no SPI or LPC controller access is needed. The window may be larger than the real flash; undecoded holes read as 0xff. This gives userspace a clean, safe way to read firmware flash contents without flashrom or relaxed /dev/mem access - for firmware analysis, and for extracting option ROMs stored inside EFI firmware volumes (e.g. the NVIDIA VBIOS on EFI-booted Apple machines, which can then be fed to nouveau via nouveau.config=NvBios=). There is deliberately no write or erase support. Tested on a MacBookPro4,1 (ICH8M): /dev/mtd0 reads are byte-identical to a flashrom dump of the 2 MiB SST25VF016B, except for live NVRAM variable-store regions. Signed-off-by: Stephen Bancroft <stevereaver@gmail.com> --- Changes in v3: - MODULE_AUTHOR: use full author identity (per Miquèl Raynal's review) Changes in v2: - Per-device state via devm_kzalloc instead of globals (fixes shared state corruption with multiple INT0800 devices) - Clean up map probe on mtd_device_register() failure (fixes memory/mapping leak) - Use %pa for resource_size_t in dev_info (fixes format string on 32-bit) - Add missing Signed-off-by drivers/mtd/maps/Kconfig | 17 ++++++ drivers/mtd/maps/Makefile | 1 + drivers/mtd/maps/int0800.c | 108 +++++++++++++++++++++++++++++++++++++ 3 files changed, 126 insertions(+) create mode 100644 drivers/mtd/maps/int0800.c diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index 1bb3dba2631d..649fd145e15d 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -161,6 +161,23 @@ config MTD_AMD76XROM BE VERY CAREFUL. +config MTD_INT0800 + tristate "Read-only BIOS/firmware flash via ACPI INT0800" + depends on X86 && ACPI + select MTD_ROM + help + Support for reading the system firmware (BIOS/EFI) flash chip + through the memory window described by the ACPI INT0800 + "82802 firmware hub" device, present on most x86 machines. + + The flash is exposed read-only via the ROM chip driver, e.g. + for firmware analysis or extracting option ROMs (such as + video BIOS images embedded in EFI firmware volumes). There is + no write or erase support. + + To compile this driver as a module, choose M here: the + module will be called int0800. + config MTD_ICHXROM tristate "BIOS flash chip on Intel Controller Hub 2/3/4/5" depends on X86 && MTD_JEDECPROBE diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile index 01745eca1f73..2f1a7375e13c 100644 --- a/drivers/mtd/maps/Makefile +++ b/drivers/mtd/maps/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_MTD_L440GX) += l440gx.o obj-$(CONFIG_MTD_AMD76XROM) += amd76xrom.o obj-$(CONFIG_MTD_ESB2ROM) += esb2rom.o obj-$(CONFIG_MTD_ICHXROM) += ichxrom.o +obj-$(CONFIG_MTD_INT0800) += int0800.o obj-$(CONFIG_MTD_CK804XROM) += ck804xrom.o obj-$(CONFIG_MTD_TSUNAMI) += tsunami_flash.o obj-$(CONFIG_MTD_PXA2XX) += pxa2xx-flash.o diff --git a/drivers/mtd/maps/int0800.c b/drivers/mtd/maps/int0800.c new file mode 100644 index 000000000000..0188d58b168d --- /dev/null +++ b/drivers/mtd/maps/int0800.c @@ -0,0 +1,108 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Read-only MTD access to the system firmware flash behind the ACPI + * INT0800 "Intel 82802 firmware hub" device. + * + * On x86 systems the boot flash is decoded into the physical address + * space below 4 GB, so a plain ioremap() is sufficient to read it - + * no SPI or LPC controller access is required. The declared _CRS + * window may be larger than the real flash (the whole top-16MiB + * decode range is commonly claimed); undecoded holes read as 0xff. + * + * The device is exposed read-only via the ROM chip driver; there is + * deliberately no write or erase support. + */ + +#include <linux/module.h> +#include <linux/acpi.h> +#include <linux/io.h> +#include <linux/mtd/mtd.h> +#include <linux/mtd/map.h> +#include <linux/platform_device.h> +#include <linux/slab.h> + +/* top-of-4GB firmware decode, used when _CRS reports no window */ +#define INT0800_DEFAULT_PHYS 0xffe00000UL +#define INT0800_DEFAULT_SIZE SZ_2M + +struct int0800 { + struct map_info map; + struct mtd_info *mtd; +}; + +static int int0800_probe(struct platform_device *pdev) +{ + struct resource *res; + struct int0800 *fw; + resource_size_t end; + int ret; + + fw = devm_kzalloc(&pdev->dev, sizeof(*fw), GFP_KERNEL); + if (!fw) + return -ENOMEM; + + fw->map.name = dev_name(&pdev->dev); + fw->map.bankwidth = 1; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res) { + fw->map.phys = res->start; + fw->map.size = resource_size(res); + } else { + fw->map.phys = INT0800_DEFAULT_PHYS; + fw->map.size = INT0800_DEFAULT_SIZE; + } + + /* + * Plain ioremap on purpose: the window is already claimed by the + * ACPI/pnp resource reservation, so devm_ioremap_resource() would + * fail with -EBUSY. + */ + fw->map.virt = devm_ioremap(&pdev->dev, fw->map.phys, fw->map.size); + if (!fw->map.virt) + return -ENOMEM; + + simple_map_init(&fw->map); + fw->mtd = do_map_probe("map_rom", &fw->map); + if (!fw->mtd) + return -ENODEV; + fw->mtd->dev.parent = &pdev->dev; + platform_set_drvdata(pdev, fw); + + end = fw->map.phys + fw->map.size - 1; + dev_info(&pdev->dev, "mapped firmware window %pa-%pa\n", + &fw->map.phys, &end); + + ret = mtd_device_register(fw->mtd, NULL, 0); + if (ret) + map_destroy(fw->mtd); + return ret; +} + +static void int0800_remove(struct platform_device *pdev) +{ + struct int0800 *fw = platform_get_drvdata(pdev); + + mtd_device_unregister(fw->mtd); + map_destroy(fw->mtd); +} + +static const struct acpi_device_id int0800_ids[] = { + { "INT0800", 0 }, + { } +}; +MODULE_DEVICE_TABLE(acpi, int0800_ids); + +static struct platform_driver int0800_driver = { + .probe = int0800_probe, + .remove = int0800_remove, + .driver = { + .name = "int0800", + .acpi_match_table = int0800_ids, + }, +}; +module_platform_driver(int0800_driver); + +MODULE_AUTHOR("Stephen Bancroft <stevereaver@gmail.com>"); +MODULE_DESCRIPTION("Read-only MTD map over the INT0800 firmware flash window"); +MODULE_LICENSE("GPL"); -- 2.43.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v3] mtd: maps: add INT0800 firmware-flash map driver 2026-09-21 2:14 ` [PATCH v3] mtd: maps: add INT0800 firmware-flash map driver Stephen Bancroft @ 2026-09-21 2:30 ` sashiko-bot 2026-09-23 9:26 ` [PATCH v4] " Stephen Bancroft 1 sibling, 0 replies; 6+ messages in thread From: sashiko-bot @ 2026-09-21 2:30 UTC (permalink / raw) To: Stephen Bancroft, linux-mtd Cc: Vignesh Raghavendra, Miquel Raynal, Richard Weinberger, linux-kernel Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] mtd: maps: Use-After-Free in int0800 via sysfs driver unbind -- commit 2d904c4a0ae5009245dd1587c804f0ac6e9402b8 Author: Stephen Bancroft <stevereaver@gmail.com> mtd: maps: add INT0800 firmware-flash map driver Adds a read-only MTD mapping driver that binds the ACPI INT0800 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..0188d58b168d9 > --- /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] Can this lead to a use-after-free and unmapped memory dereference if a user forces a driver unbind via sysfs while the character device is still open? If a privileged user opens /dev/mtdX and then writes to /sys/bus/platform/drivers/int0800/unbind, int0800_remove() is invoked. This unconditionally calls map_destroy(fw->mtd), freeing the mtd_info structure and allowing devres to unmap fw->map.virt. Since mtdchar_open() incrementing the module use-count does not prevent forced sysfs unbinds, a subsequent read() on the still-open file descriptor would dereference the freed mtd_info and read from the unmapped memory. Should this driver set .suppress_bind_attrs = true in the platform_driver to prevent forced sysfs unbinds? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260921021459.283023-1-stevereaver@gmail.com?part=1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4] mtd: maps: add INT0800 firmware-flash map driver 2026-09-21 2:14 ` [PATCH v3] mtd: maps: add INT0800 firmware-flash map driver Stephen Bancroft 2026-09-21 2:30 ` sashiko-bot @ 2026-09-23 9:26 ` Stephen Bancroft 2026-09-23 9:41 ` sashiko-bot 2026-09-25 14:29 ` Miquel Raynal 1 sibling, 2 replies; 6+ messages in thread From: Stephen Bancroft @ 2026-09-23 9:26 UTC (permalink / raw) To: linux-mtd Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, linux-kernel, Stephen Bancroft 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. On x86 machines the boot flash is decoded into the physical address space below 4 GB, so a plain ioremap() of the declared resource window is sufficient for reads - no SPI or LPC controller access is needed. The window may be larger than the real flash; undecoded holes read as 0xff. This gives userspace a clean, safe way to read firmware flash contents without flashrom or relaxed /dev/mem access - for firmware analysis, and for extracting option ROMs stored inside EFI firmware volumes (e.g. the NVIDIA VBIOS on EFI-booted Apple machines, which can then be fed to nouveau via nouveau.config=NvBios=). There is deliberately no write or erase support. Tested on a MacBookPro4,1 (ICH8M): /dev/mtd0 reads are byte-identical to a flashrom dump of the 2 MiB SST25VF016B, except for live NVRAM variable-store regions. Signed-off-by: Stephen Bancroft <stevereaver@gmail.com> --- Changes in v4: - Set .suppress_bind_attrs: remove() frees the mtd_info and lets devres unmap the window unconditionally, so a sysfs driver unbind while a /dev/mtdX fd is still open would leave userspace holding a dangling pointer into freed/unmapped memory (Sashiko AI review). Module unload is now the only teardown path and is already blocked by open fds via mtd->owner. Changes in v3: - MODULE_AUTHOR: use full author identity (per Miquèl Raynal's review) Changes in v2: - Per-device state via devm_kzalloc instead of globals (fixes shared state corruption with multiple INT0800 devices) - Clean up map probe on mtd_device_register() failure (fixes memory/mapping leak) - Use %pa for resource_size_t in dev_info (fixes format string on 32-bit) - Add missing Signed-off-by drivers/mtd/maps/Kconfig | 17 ++++++ drivers/mtd/maps/Makefile | 1 + drivers/mtd/maps/int0800.c | 115 +++++++++++++++++++++++++++++++++++++ 3 files changed, 133 insertions(+) create mode 100644 drivers/mtd/maps/int0800.c diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index 1bb3dba2631d..649fd145e15d 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -161,6 +161,23 @@ config MTD_AMD76XROM BE VERY CAREFUL. +config MTD_INT0800 + tristate "Read-only BIOS/firmware flash via ACPI INT0800" + depends on X86 && ACPI + select MTD_ROM + help + Support for reading the system firmware (BIOS/EFI) flash chip + through the memory window described by the ACPI INT0800 + "82802 firmware hub" device, present on most x86 machines. + + The flash is exposed read-only via the ROM chip driver, e.g. + for firmware analysis or extracting option ROMs (such as + video BIOS images embedded in EFI firmware volumes). There is + no write or erase support. + + To compile this driver as a module, choose M here: the + module will be called int0800. + config MTD_ICHXROM tristate "BIOS flash chip on Intel Controller Hub 2/3/4/5" depends on X86 && MTD_JEDECPROBE diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile index 01745eca1f73..2f1a7375e13c 100644 --- a/drivers/mtd/maps/Makefile +++ b/drivers/mtd/maps/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_MTD_L440GX) += l440gx.o obj-$(CONFIG_MTD_AMD76XROM) += amd76xrom.o obj-$(CONFIG_MTD_ESB2ROM) += esb2rom.o obj-$(CONFIG_MTD_ICHXROM) += ichxrom.o +obj-$(CONFIG_MTD_INT0800) += int0800.o obj-$(CONFIG_MTD_CK804XROM) += ck804xrom.o obj-$(CONFIG_MTD_TSUNAMI) += tsunami_flash.o obj-$(CONFIG_MTD_PXA2XX) += pxa2xx-flash.o diff --git a/drivers/mtd/maps/int0800.c b/drivers/mtd/maps/int0800.c new file mode 100644 index 000000000000..c5f108aa3479 --- /dev/null +++ b/drivers/mtd/maps/int0800.c @@ -0,0 +1,115 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Read-only MTD access to the system firmware flash behind the ACPI + * INT0800 "Intel 82802 firmware hub" device. + * + * On x86 systems the boot flash is decoded into the physical address + * space below 4 GB, so a plain ioremap() is sufficient to read it - + * no SPI or LPC controller access is required. The declared _CRS + * window may be larger than the real flash (the whole top-16MiB + * decode range is commonly claimed); undecoded holes read as 0xff. + * + * The device is exposed read-only via the ROM chip driver; there is + * deliberately no write or erase support. + */ + +#include <linux/module.h> +#include <linux/acpi.h> +#include <linux/io.h> +#include <linux/mtd/mtd.h> +#include <linux/mtd/map.h> +#include <linux/platform_device.h> +#include <linux/slab.h> + +/* top-of-4GB firmware decode, used when _CRS reports no window */ +#define INT0800_DEFAULT_PHYS 0xffe00000UL +#define INT0800_DEFAULT_SIZE SZ_2M + +struct int0800 { + struct map_info map; + struct mtd_info *mtd; +}; + +static int int0800_probe(struct platform_device *pdev) +{ + struct resource *res; + struct int0800 *fw; + resource_size_t end; + int ret; + + fw = devm_kzalloc(&pdev->dev, sizeof(*fw), GFP_KERNEL); + if (!fw) + return -ENOMEM; + + fw->map.name = dev_name(&pdev->dev); + fw->map.bankwidth = 1; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res) { + fw->map.phys = res->start; + fw->map.size = resource_size(res); + } else { + fw->map.phys = INT0800_DEFAULT_PHYS; + fw->map.size = INT0800_DEFAULT_SIZE; + } + + /* + * Plain ioremap on purpose: the window is already claimed by the + * ACPI/pnp resource reservation, so devm_ioremap_resource() would + * fail with -EBUSY. + */ + fw->map.virt = devm_ioremap(&pdev->dev, fw->map.phys, fw->map.size); + if (!fw->map.virt) + return -ENOMEM; + + simple_map_init(&fw->map); + fw->mtd = do_map_probe("map_rom", &fw->map); + if (!fw->mtd) + return -ENODEV; + fw->mtd->dev.parent = &pdev->dev; + platform_set_drvdata(pdev, fw); + + end = fw->map.phys + fw->map.size - 1; + dev_info(&pdev->dev, "mapped firmware window %pa-%pa\n", + &fw->map.phys, &end); + + ret = mtd_device_register(fw->mtd, NULL, 0); + if (ret) + map_destroy(fw->mtd); + return ret; +} + +static void int0800_remove(struct platform_device *pdev) +{ + struct int0800 *fw = platform_get_drvdata(pdev); + + mtd_device_unregister(fw->mtd); + map_destroy(fw->mtd); +} + +static const struct acpi_device_id int0800_ids[] = { + { "INT0800", 0 }, + { } +}; +MODULE_DEVICE_TABLE(acpi, int0800_ids); + +static struct platform_driver int0800_driver = { + .probe = int0800_probe, + .remove = int0800_remove, + .driver = { + .name = "int0800", + .acpi_match_table = int0800_ids, + /* + * remove() frees the mtd_info and unmaps the window even + * while /dev/mtdX fds are still open; the only safe + * teardown path is module unload, which open fds block + * via mtd->owner. + */ + .suppress_bind_attrs = true, + }, +}; +module_platform_driver(int0800_driver); + +MODULE_AUTHOR("Stephen Bancroft <stevereaver@gmail.com>"); +MODULE_DESCRIPTION("Read-only MTD map over the INT0800 firmware flash window"); +MODULE_LICENSE("GPL"); -- 2.43.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v4] mtd: maps: add INT0800 firmware-flash map driver 2026-09-23 9:26 ` [PATCH v4] " Stephen Bancroft @ 2026-09-23 9:41 ` sashiko-bot 2026-09-23 11:57 ` Steve Reaver 2026-09-25 14:29 ` Miquel Raynal 1 sibling, 1 reply; 6+ messages in thread From: sashiko-bot @ 2026-09-23 9:41 UTC (permalink / raw) To: Stephen Bancroft, linux-mtd Cc: Richard Weinberger, linux-kernel, Vignesh Raghavendra, Miquel Raynal 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 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] mtd: maps: add INT0800 firmware-flash map driver 2026-09-23 9:41 ` sashiko-bot @ 2026-09-23 11:57 ` Steve Reaver 0 siblings, 0 replies; 6+ messages in thread From: Steve Reaver @ 2026-09-23 11:57 UTC (permalink / raw) To: sashiko-reviews Cc: linux-mtd, Richard Weinberger, linux-kernel, Vignesh Raghavendra, Miquel Raynal The remaining removal paths don't apply to this device. The platform device is only unregistered via ACPI_RECONFIG_DEVICE_REMOVE, which requires the INT0800 ACPI node to leave the namespace. INT0800 is a static DSDT device: it has no _EJ0 (the eject sysfs attribute is never created for it), cannot live in an unloadable SSDT overlay, and has no hotplug notify source. Unbinding a parent device/driver does not invoke a child's remove(). With .suppress_bind_attrs the sysfs unbind is gone, and module unload is blocked by open fds via mtd->owner. The residual "rmmod -f with CONFIG_MODULE_FORCE_UNLOAD" bypasses refcounting for every driver. FWIW, the underlying limitation — map providers freeing mtd_info while the core cannot wait for open fds — is shared by all existing drivers/mtd/maps users; addressing it would be an MTD core lifetime change beyond this driver. On Wed, 23 Sept 2026 at 19:41, <sashiko-bot@kernel.org> wrote: > > 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 -- Steve Reaver http://www.stevereaver.com/ Electronic Music Production ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] mtd: maps: add INT0800 firmware-flash map driver 2026-09-23 9:26 ` [PATCH v4] " Stephen Bancroft 2026-09-23 9:41 ` sashiko-bot @ 2026-09-25 14:29 ` Miquel Raynal 1 sibling, 0 replies; 6+ messages in thread From: Miquel Raynal @ 2026-09-25 14:29 UTC (permalink / raw) To: linux-mtd, Stephen Bancroft Cc: Richard Weinberger, Vignesh Raghavendra, linux-kernel On Wed, 23 Sep 2026 19:26:24 +1000, Stephen Bancroft wrote: > 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. > > On x86 machines the boot flash is decoded into the physical address > space below 4 GB, so a plain ioremap() of the declared resource window > is sufficient for reads - no SPI or LPC controller access is needed. > The window may be larger than the real flash; undecoded holes read as > 0xff. > > [...] Applied to mtd/next, thanks! [1/1] mtd: maps: add INT0800 firmware-flash map driver commit: c4f64a86a28d218f3b16cd7b18691993aa60db60 Patche(s) should be available on mtd/linux.git and will be part of the next PR (provided that no robot complains by then). Kind regards, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-25 14:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <V2-MESSAGE-ID>
2026-09-21 2:14 ` [PATCH v3] mtd: maps: add INT0800 firmware-flash map driver 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
2026-09-23 11:57 ` Steve Reaver
2026-09-25 14:29 ` Miquel Raynal
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox