stmmac_change_mtu() releases the current DMA configuration and then
reopens the interface with a freshly allocated dma_conf.  __stmmac_open()
copies that dma_conf into priv->dma_conf via memcpy() before it can fail
(e.g. in stmmac_request_irq()).  When it does fail, the error path frees
the dma_conf descriptor resources and the struct itself, but priv->dma_conf
still holds pointers to those freed resources.  The interface remains
running, so a subsequent stmmac_release() or another MTU change releases
those resources a second time, a use-after-free.

Zero out priv->dma_conf after freeing the failed configuration so the
stale pointers are not released again.

Fixes: 30134b7c47bd2 ("net: ethernet: stmicro: stmmac: fix possible memory leak in __stmmac_open")
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f2fc89176654ed07dafc30ea1dd481d9f08fb120..9d4b93a64e32f375ef9ee4917f60c40ce2409f07 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6132,6 +6132,7 @@ static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
 		if (ret) {
 			free_dma_desc_resources(priv, dma_conf);
 			kfree(dma_conf);
+			memset(&priv->dma_conf, 0, sizeof(priv->dma_conf));
 			netdev_err(priv->dev, "failed reopening the interface after MTU change\n");
 			return ret;
 		}

---
base-commit: 940de590b839f71d6dc846160534bf202401b8b7
change-id: 20260903-fix-stmmac-mtu-change-use-after-free-693da6eb4a30

Best regards,
-- 
ZhaoJinming <zhaojinming@uniontech.com>

Hi,

On 9/3/26 12:50, ZhaoJinming wrote:
> stmmac_change_mtu() releases the current DMA configuration and then
> reopens the interface with a freshly allocated dma_conf.  __stmmac_open()
> copies that dma_conf into priv->dma_conf via memcpy() before it can fail
> (e.g. in stmmac_request_irq()).  When it does fail, the error path frees
> the dma_conf descriptor resources and the struct itself, but priv->dma_conf
> still holds pointers to those freed resources.

Following that logic, it seems that the problem is rather that __stmmac_open()
should clear its priv->dma_conf in the error path. It would undo what was done,
leaving the state consistent.

Maxime