In xgmac_probe, &priv->tx_timeout_work is bound with
xgmac_tx_timeout_work, and xgmac_interrupt and xgmac_tx_timeout can
both schedule this work on system_wq.

If we remove the device, xgmac_remove makes cleanup and the memory
allocated for priv with netdev_priv() is released by free_netdev(),
while the work mentioned above may still be pending or running. The
sequence of operations that may lead to a UAF bug is as follows:

CPU0                                      CPU1

                                          | xgmac_interrupt
                                          | schedule_work(&priv->tx_timeout_work)
xgmac_remove                              |
xgmac_mac_disable(priv->base)             |
free_irq(ndev->irq, ndev)                 |
free_irq(priv->pmt_irq, ndev)             |
unregister_netdev(ndev)                   |
netif_napi_del(&priv->napi)               |
iounmap(priv->base)                       |
free_netdev(ndev)                         |
// priv is freed                          |
                                          | xgmac_tx_timeout_work
                                          | // use priv (use-after-free)

Fix it by canceling the work after the sources that can schedule it
(IRQ handler and the kernel netdev watchdog dev_watchdog, which calls
ndo_tx_timeout) have been stopped, and before proceeding with the
remaining cleanup in xgmac_remove.

Fixes: 8746f671ef04 ("net: calxedaxgmac: fix race between xgmac_tx_complete and xgmac_tx_err")
Assisted-by: Codex:deepseek-v4-flash
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
 drivers/net/ethernet/calxeda/xgmac.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
index a2410fba6be2..a692a9ad19d3 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -1830,6 +1830,9 @@ static void xgmac_remove(struct platform_device *pdev)
 	free_irq(priv->pmt_irq, ndev);
 
 	unregister_netdev(ndev);
+
+	cancel_work_sync(&priv->tx_timeout_work);
+
 	netif_napi_del(&priv->napi);
 
 	iounmap(priv->base);
-- 
2.25.1

On Tue,  4 Aug 2026 10:21:26 +0800 Pei Xiao wrote:
> In xgmac_probe, &priv->tx_timeout_work is bound with
> xgmac_tx_timeout_work, and xgmac_interrupt and xgmac_tx_timeout can
> both schedule this work on system_wq.

AI reviewer reports that this can add a deadlock.

Looks like we're trading one bug for another.

If you don't have access to this HW or ability to test your patches
in general - please don't try to send such superficial fixes.
-- 
pw-bot: reject

在 2026/8/11 05:43, Jakub Kicinski 写道:
> On Tue,  4 Aug 2026 10:21:26 +0800 Pei Xiao wrote:
>> In xgmac_probe, &priv->tx_timeout_work is bound with
>> xgmac_tx_timeout_work, and xgmac_interrupt and xgmac_tx_timeout can
>> both schedule this work on system_wq.
> 
> AI reviewer reports that this can add a deadlock.
> 
> Looks like we're trading one bug for another.
> 
> If you don't have access to this HW or ability to test your patches
> in general - please don't try to send such superficial fixes.
Sorry for making noise. Does this issue exist, and does it need to be
fixed? If it needs to be fixed, I'd like to learn how it ends up being fixed

Pei.
Thanks.

On Tue, 11 Aug 2026 09:33:42 +0800 Pei Xiao wrote:
> 在 2026/8/11 05:43, Jakub Kicinski 写道:
> > On Tue,  4 Aug 2026 10:21:26 +0800 Pei Xiao wrote:  
> >> In xgmac_probe, &priv->tx_timeout_work is bound with
> >> xgmac_tx_timeout_work, and xgmac_interrupt and xgmac_tx_timeout can
> >> both schedule this work on system_wq.  
> > 
> > AI reviewer reports that this can add a deadlock.
> > 
> > Looks like we're trading one bug for another.
> > 
> > If you don't have access to this HW or ability to test your patches
> > in general - please don't try to send such superficial fixes.  
> Sorry for making noise. Does this issue exist, and does it need to be
> fixed? If it needs to be fixed, I'd like to learn how it ends up being fixed

Your 3 recent submissions were all inadequate. Please leave networking
drivers be. It will take us more time to review your code than fix
these. And you're touching drivers which nobody worked on for 
_15 years_!