[PATCH net] net: stmmac: Disable queues before netif_tx_disable in xdp_release

[PATCH net] net: stmmac: Disable queues before netif_tx_disable in xdp_release

[muhammad.nazim.amirul.nazle.asmade]

From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

stmmac_xdp_release() calls netif_tx_disable() before
stmmac_disable_all_queues(), which creates a race window where NAPI
is still running while TX is being disabled. If a packet is still
queued at that point, it can be processed after TX is stopped,
leading to a kernel panic.

Fix this by calling stmmac_disable_all_queues() first to stop NAPI
processing before disabling TX, matching the order already used in
stmmac_release() since 7028471edb64.

Fixes: 7028471edb64 ("net: ethernet: stmicro: stmmac: first disable all queues and disconnect in release")
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..75cb53938519 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7099,15 +7099,15 @@ void stmmac_xdp_release(struct net_device *dev)
 	struct stmmac_priv *priv = netdev_priv(dev);
 	u8 chan;
 
-	/* Ensure tx function is not running */
-	netif_tx_disable(dev);
-
 	/* Disable NAPI process */
 	stmmac_disable_all_queues(priv);
 
 	for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)
 		hrtimer_cancel(&priv->dma_conf.tx_queue[chan].txtimer);
 
+	/* Ensure tx function is not running */
+	netif_tx_disable(dev);
+
 	/* Free the IRQ lines */
 	stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0);
 
-- 
2.43.7

Re: [PATCH net] net: stmmac: Disable queues before netif_tx_disable in xdp_release

[Maxime Chevallier]

Hi,

On 7/27/26 05:06, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> 
> stmmac_xdp_release() calls netif_tx_disable() before
> stmmac_disable_all_queues(), which creates a race window where NAPI
> is still running while TX is being disabled. If a packet is still
> queued at that point, it can be processed after TX is stopped,
> leading to a kernel panic.
> 
> Fix this by calling stmmac_disable_all_queues() first to stop NAPI
> processing before disabling TX, matching the order already used in
> stmmac_release() since 7028471edb64.
> 
> Fixes: 7028471edb64 ("net: ethernet: stmicro: stmmac: first disable all queues and disconnect in release")
> Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Maxime

Re: [PATCH net] net: stmmac: Disable queues before netif_tx_disable in xdp_release

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Critical] Reordering `netif_tx_disable()` after `hrtimer_cancel()` introduces a TOCTOU race where a concurrent `ndo_start_xmit` can arm the TX timer after it has been canceled, leading to timer RB-tree corruption.

Pre-existing issues:
- [Critical] `stmmac_xdp_release()` frees DMA descriptor resources without synchronizing with concurrent `ndo_xdp_xmit` (XDP redirects) or fully stopping packet transmission, leading to a Use-After-Free.
- [Critical] `stmmac_xdp_set_prog()` ignores the return value of `stmmac_xdp_open()`, leading to a UAF if DMA descriptor allocation fails.
--

--- Patch [1]: [PATCH net] net: stmmac: Disable queues before netif_tx_disable in xdp_release ---
commit b78d98cf884a90fa124b2eaf510b02a6bb8585af
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

net: stmmac: Disable queues before netif_tx_disable in xdp_release

stmmac_xdp_release() calls netif_tx_disable() before
stmmac_disable_all_queues(), which creates a race window where NAPI
is still running while TX is being disabled. If a packet is still
queued at that point, it can be processed after TX is stopped,
leading to a kernel panic.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 151c77713025c..d806687788a8d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -7085,15 +7085,15 @@ void stmmac_xdp_release(struct net_device *dev)
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  	u8 chan;
>  
> -	/* Ensure tx function is not running */
> -	netif_tx_disable(dev);
> -
>  	/* Disable NAPI process */
>  	stmmac_disable_all_queues(priv);
>  
>  	for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)
>  		hrtimer_cancel(&priv->dma_conf.tx_queue[chan].txtimer);
>  
> +	/* Ensure tx function is not running */
> +	netif_tx_disable(dev);

[Severity: Critical]
By reordering netif_tx_disable() after hrtimer_cancel(), does this introduce a
race where a concurrent ndo_start_xmit() can re-arm the TX timer after it has
been canceled?

If CPU 1 is in stmmac_tx_timer_arm() (via ndo_start_xmit) and evaluates
!napi_is_scheduled() as true:

CPU 1
stmmac_tx_timer_arm()
    if (!napi_is_scheduled(...)) {

CPU 0 could then execute stmmac_disable_all_queues() and hrtimer_cancel().

When CPU 1 resumes, it will call hrtimer_start() to arm the timer. CPU 0 then
calls netif_tx_disable(), but the timer is already armed and survives the
teardown, potentially leading to hrtimer RB-tree corruption.

> +
>  	/* Free the IRQ lines */
>  	stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0);
>  

While looking at this file, I noticed a pre-existing issue further down in
stmmac_xdp_release():

> 	/* Stop TX/RX DMA channels */
> 	stmmac_stop_all_dma(priv);
> 
> 	/* Release and free the Rx/Tx resources */
> 	free_dma_desc_resources(priv, &priv->dma_conf);

[Severity: Critical]
This is a pre-existing issue, but does stmmac_xdp_release() free DMA
descriptor resources without synchronizing with concurrent XDP redirects?

Since STMMAC_DOWN is not set here and no RCU synchronization has occurred to
wait for XDP, if another interface processes an XDP redirect and invokes
stmmac_xdp_xmit():

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:stmmac_xdp_xmit() {
    ...
	if (unlikely(test_bit(STMMAC_DOWN, &priv->state)))
		return -ENETDOWN;
    ...
}

Will this proceed to write packet data to the freed tx_skbuff_dma array,
leading to a use-after-free?


I also noticed another pre-existing issue in stmmac_xdp_set_prog():

drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c:stmmac_xdp_set_prog() {
    ...
> 	/* Disable RX SPH for XDP operation */
> 	priv->sph_active = priv->sph_capable && !stmmac_xdp_is_enabled(priv);
> 
> 	if (if_running && need_update)
> 		stmmac_xdp_open(dev);
> 
> 	if (prog)
> 		xdp_features_set_redirect_target(dev, false);
> 
> 	return 0;
> }

[Severity: Critical]
This is a pre-existing issue, but does this code ignore the return value of
stmmac_xdp_open()?

If stmmac_xdp_open() fails, it frees all DMA resources and returns an error.
Because stmmac_xdp_set_prog() ignores this error and returns 0, the device
remains logically UP but with freed DMA rings.

Could subsequent XDP redirects then invoke stmmac_xdp_xmit() and access the
freed tx_skbuff_dma structures?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727030645.13280-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=1