Re: [PATCH v3 5/7] PCI: aardvark: Add 100 ms delay after link training

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] Potential Use-After-Free (UAF) in the IRQ handler during advk_pcie_probe() failure due to unbalanced teardown symmetry.
- [High] Memory and hardware resources are leaked in the error paths of advk_pcie_probe().
- [Medium] The commit message incorrectly claims that `link_gen` holds the negotiated link speed.
--

commit 1f92b585affbc960f9cf75de361f24796312c8bb
Author: Hans Zhang <18255117159@163.com>

PCI: aardvark: Add 100 ms delay after link training

This commit introduces a 100 ms delay after PCIe link training completes for
speeds greater than 5.0 GT/s. It utilizes the existing pcie->link_gen field
and pci_host_common_link_train_delay() to implement this requirement.

> The driver already maintains a 'link_gen' field that holds the negotiated
> link speed. Use it together with pci_host_common_link_train_delay() to
> insert the required delay immediately after confirming that the link
> is up.

This isn't a bug, but is this description accurate? The pcie->link_gen field
is populated during driver probe via of_pci_get_max_link_speed() and does
not appear to be dynamically updated with the actual negotiated link speed
from the hardware.

[ ... ]

Looking at the error paths in advk_pcie_probe(), if steps like
advk_pcie_init_irq_domain() or pci_host_probe() fail, the driver returns
without calling pci_bridge_emul_cleanup() to free the emulated bridge memory.
It also appears to skip calling advk_pcie_disable_phy() to power off the PHY.

Does this code leak the PHY and emulated bridge memory resources in these
error paths?

Also in advk_pcie_probe(), the driver registers advk_pcie_irq_handler using
devm_request_irq() and enables hardware interrupts via advk_pcie_setup_hw().

If a later step like pci_host_probe() fails, the error path calls
advk_pcie_remove_irq_domain(), which frees the irq domain.

Since the hardware interrupts are not masked and the IRQ handler is not
deregistered in this error path, devm_request_irq() defers unregistration
until after the probe function returns.

Could a hardware interrupt fire in this window, causing
advk_pcie_irq_handler() to call generic_handle_domain_irq() and dereference
the freed pcie->irq_domain pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511055923.37117-1-18255117159@163.com?part=5