Re: [PATCH v4 3/3] PCI: ultrarisc: use module_platform_driver()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Replacing `builtin_platform_driver()` with `module_platform_driver()` without a `.remove` callback enables unsafe module unloading, leading to a critical use-after-free vulnerability.
--

--- Patch [3]: [PATCH v4 3/3] PCI: ultrarisc: use module_platform_driver() ---
commit d768b3fb3030b38d7fa1abda1368c3ffe340185e
Author: Jia Wang <[email protected]>

PCI: ultrarisc: use module_platform_driver()

This commit updates the driver registration to use module_platform_driver()
to support building as a module. It explicitly leaves the .remove callback
unset to prevent disposing of the internal MSI controller during removal.

> diff --git a/drivers/pci/controller/dwc/pcie-ultrarisc.c b/drivers/pci/controller/dwc/pcie-ultrarisc.c
> --- a/drivers/pci/controller/dwc/pcie-ultrarisc.c
> +++ b/drivers/pci/controller/dwc/pcie-ultrarisc.c
[ ... ]
> @@ -240,7 +240,7 @@ static struct platform_driver ultrarisc_pcie_driver = {
>  	},
>  	.probe = ultrarisc_pcie_probe,
>  };
> -builtin_platform_driver(ultrarisc_pcie_driver);
> +module_platform_driver(ultrarisc_pcie_driver);

[Severity: Critical]
Does using module_platform_driver() here make the module unloadable,
potentially leading to a use-after-free?

Since the .remove callback is left unset, driver-specific teardown like
dw_pcie_host_deinit() is skipped on unload. However, the driver core will
still unbind the device and automatically free all devm-managed memory,
such as the core structure allocated in ultrarisc_pcie_probe():

ultra = devm_kzalloc(dev, sizeof(*ultra), GFP_KERNEL);

Because the PCI host bridge and IRQ domains are not unregistered, they will
remain active in the system with dangling pointers to this freed memory.
Would subsequent accesses to the PCI bus (like sysfs reads or interrupts)
dereference these dangling pointers when the module text is unmapped?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3