* Re: [PATCH] PCI: mediatek: fix W=1 snpringf warnings
2026-03-03 1:46 [PATCH] PCI: mediatek: fix W=1 snpringf warnings Ryder Lee
@ 2026-03-21 12:24 ` Manivannan Sadhasivam
2026-10-02 23:39 ` Bjorn Helgaas
1 sibling, 0 replies; 3+ messages in thread
From: Manivannan Sadhasivam @ 2026-03-21 12:24 UTC (permalink / raw)
To: Bjorn Helgaas, Rob Herring, Ryder Lee
Cc: Jianjun Wang, Krzysztof Wilczyński, Lorenzo Pieralisi,
linux-mediatek, linux-pci
On Mon, 02 Mar 2026 17:46:48 -0800, Ryder Lee wrote:
> Fix the following errors in W=1 builds.
>
> $ make W=1 drivers/pci/controller/pcie-mediatek.o
> CALL scripts/checksyscalls.sh
> DESCEND objtool
> INSTALL libsubcmd_headers
> CC drivers/pci/controller/pcie-mediatek.o
> drivers/pci/controller/pcie-mediatek.c: In function ‘mtk_pcie_parse_port’:
> drivers/pci/controller/pcie-mediatek.c:963:43: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Werror=format-truncation=]
> 963 | snprintf(name, sizeof(name), "port%d", slot);
> | ^~
> drivers/pci/controller/pcie-mediatek.c:963:38: note: directive argument in the range [0, 2147483647]
> 963 | snprintf(name, sizeof(name), "port%d", slot);
> | ^~~~~~~~
> drivers/pci/controller/pcie-mediatek.c:963:9: note: ‘snprintf’ output between 6 and 15 bytes into a destination of size 10
> 963 | snprintf(name, sizeof(name), "port%d", slot);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> [...]
Applied, thanks!
[1/1] PCI: mediatek: fix W=1 snpringf warnings
commit: ab4a4043db1fcc4fd4c5745c5be8caf053502e29
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] PCI: mediatek: fix W=1 snpringf warnings
2026-03-03 1:46 [PATCH] PCI: mediatek: fix W=1 snpringf warnings Ryder Lee
2026-03-21 12:24 ` Manivannan Sadhasivam
@ 2026-10-02 23:39 ` Bjorn Helgaas
1 sibling, 0 replies; 3+ messages in thread
From: Bjorn Helgaas @ 2026-10-02 23:39 UTC (permalink / raw)
To: Ryder Lee
Cc: Bjorn Helgaas, Rob Herring, Jianjun Wang, Manivannan Sadhasivam,
Krzysztof Wilczyński, Lorenzo Pieralisi, linux-mediatek,
linux-pci
On Mon, Mar 02, 2026 at 05:46:48PM -0800, Ryder Lee wrote:
> Fix the following errors in W=1 builds.
>
> $ make W=1 drivers/pci/controller/pcie-mediatek.o
> CALL scripts/checksyscalls.sh
> DESCEND objtool
> INSTALL libsubcmd_headers
> CC drivers/pci/controller/pcie-mediatek.o
> drivers/pci/controller/pcie-mediatek.c: In function ‘mtk_pcie_parse_port’:
> drivers/pci/controller/pcie-mediatek.c:963:43: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Werror=format-truncation=]
> 963 | snprintf(name, sizeof(name), "port%d", slot);
> | ^~
> drivers/pci/controller/pcie-mediatek.c:963:38: note: directive argument in the range [0, 2147483647]
> 963 | snprintf(name, sizeof(name), "port%d", slot);
> | ^~~~~~~~
> drivers/pci/controller/pcie-mediatek.c:963:9: note: ‘snprintf’ output between 6 and 15 bytes into a destination of size 10
> 963 | snprintf(name, sizeof(name), "port%d", slot);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -953,7 +953,7 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
> struct mtk_pcie_port *port;
> struct device *dev = pcie->dev;
> struct platform_device *pdev = to_platform_device(dev);
> - char name[10];
> + char name[20];
> int err;
FYI, from internal Sashiko review while backporting this:
[Severity: High]
This is a pre-existing issue, but looking at the error paths around port
parsing, is there a missing IRQ teardown that could lead to a use-after-free
or resource leak?
When mtk_pcie_parse_port() successfully parses a port, mtk_pcie_setup_irq()
allocates an IRQ domain and registers a chained IRQ handler that keeps a
pointer to the port struct.
If a subsequent initialization step fails, such as parsing another port in
mtk_pcie_setup() or pci_host_probe() failing in mtk_pcie_probe(), the probe
function aborts and returns an error:
mtk_pcie_setup() {
...
err = mtk_pcie_parse_port(pcie, child, slot);
if (err)
return err;
...
}
The error paths, such as the put_resources label in mtk_pcie_probe() which
calls mtk_pcie_put_resources(), will free the memory of the port struct but
fail to unregister the chained IRQ handler or remove the IRQ domain.
Because of this, a freed port pointer remains registered as the handler data.
If the shared interrupt fires, could mtk_pcie_intr_handler() dereference this
freed pointer and crash?
Additionally, if platform_get_irq() fails in mtk_pcie_setup_irq(), it looks
like the function returns an error without destroying the just-created
port->irq_domain:
mtk_pcie_setup_irq() {
...
if (port->irq < 0)
return port->irq;
...
}
Would it be appropriate to add proper teardown functions to these error paths
to unregister the handlers and clean up the domains?
^ permalink raw reply [flat|nested] 3+ messages in thread