From: sashiko-bot@kernel.org
To: "Jia Wang" <wangjia@ultrarisc.com>
Cc: conor+dt@kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v4 3/3] PCI: ultrarisc: use module_platform_driver()
Date: Fri, 31 Jul 2026 01:31:38 +0000 [thread overview]
Message-ID: <20260731013139.1D4751F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260731-ultrarisc-pci-clk-v4-3-d738b491e49a@ultrarisc.com>
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 <wangjia@ultrarisc.com>
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/20260731-ultrarisc-pci-clk-v4-0-d738b491e49a@ultrarisc.com?part=3
prev parent reply other threads:[~2026-07-31 1:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 1:14 [PATCH v4 0/3] PCI: ultrarisc: Add DP1000 PCIe clock support Jia Wang
2026-07-31 1:14 ` Jia Wang via B4 Relay
2026-07-31 1:14 ` [PATCH v4 1/3] dt-bindings: pci: ultrarisc: add required DP1000 PCIe clocks Jia Wang
2026-07-31 1:14 ` Jia Wang via B4 Relay
2026-07-31 1:25 ` sashiko-bot
2026-07-31 1:14 ` [PATCH v4 2/3] PCI: ultrarisc: get and enable " Jia Wang
2026-07-31 1:14 ` Jia Wang via B4 Relay
2026-07-31 1:27 ` sashiko-bot
2026-07-31 1:14 ` [PATCH v4 3/3] PCI: ultrarisc: use module_platform_driver() Jia Wang
2026-07-31 1:14 ` Jia Wang via B4 Relay
2026-07-31 1:31 ` sashiko-bot [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=20260731013139.1D4751F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wangjia@ultrarisc.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.