| Message ID | 20260904080758.2432748-1-dayou5941@163.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-25562-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74]) by mxe881.netcup.net (Postfix) with ESMTPS id DCE721C0BF9 for <noreply@patchwork.local>; Fri, 4 Sep 2026 10:12:59 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=163.com; spf=pass (sender IP is 172.232.135.74) smtp.mailfrom=linux-sunxi+bounces-25562-noreply=patchwork.local@lists.linux.dev smtp.helo=sto.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.232.135.74 as permitted sender) client-ip=172.232.135.74; envelope-from=linux-sunxi+bounces-25562-noreply=patchwork.local@lists.linux.dev; helo=sto.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id 98CCC6036FF for <noreply@patchwork.local>; Fri, 4 Sep 2026 08:08:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B689430F803; Fri, 4 Sep 2026 08:08:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="NMKb0u7u" X-Original-To: linux-sunxi@lists.linux.dev Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D61823DD528 for <linux-sunxi@lists.linux.dev>; Fri, 4 Sep 2026 08:08:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788509334; cv=none; b=aP2sNm0K4znNKUv5L15M/X4ItpOqh7AL8s+9L1baZAWD2cyd+1Hl9IdJ4N7YKX6nS2FW3wlc406Cdtbgu8AslP3y8D0CkQABz75CIzW3wXQbe/2pBVg+TQAOsWzW0UfufErrnckZqzoR8dglMhL7uBNGQmwfKLjiCzKhZY0fnO4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788509334; c=relaxed/simple; bh=pE7cN1GvzbE2y4nwVf6pbJQ5LYB0P93SIyPfPfCW1Mo=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=uAedp0VL40B/wjUfbuqNO6OrE37IuOk5bbdav2Q9kBNjgM1USJgBUi0zwjdB0OuqbOwgiZApBNW1Qt9QU6xZnJ58aZ8hbTKwXghC/dw/fuRAXV41FtpzhnYhRoQih5GK4svxCaHGSjmW4LNopJvWYP8PSJQrfm3OMthbOq446NY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=NMKb0u7u; arc=none smtp.client-ip=117.135.210.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=MO 4pXFcedS4dIGPS5osjZgGZ/rrJKJyCM5L1ro6VuTQ=; b=NMKb0u7uyy3F22NI3E aiY6QZGK/jVPlW/3ITEC3qYdLhsgfyTtX31/7Z7KNBsyPJrM4taXLSRN0JDKvnGX r3GGj6WwnUGf0rufp8D3fY6JhBYUTFq8oUHiX1XXw5Vz0hhRAK13kR8jXDyKhS7o 9WXMNQZou0RTrvdcjAOMRMhgY= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wB37GlgfJpqs61iAg--.12312S2; Fri, 04 Sep 2026 16:08:01 +0800 (CST) From: "Li Youhong" <dayou5941@163.com> To: netdev@vger.kernel.org Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, wens@kernel.org, jernej.skrabec@gmail.com, samuel@sholland.org, linux-sunxi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Li Youhong <liyouhong@kylinos.cn> Subject: [PATCH] net: sun4i-emac: fix missing of_node_put() for phy_node Date: Fri, 4 Sep 2026 16:07:58 +0800 Message-Id: <20260904080758.2432748-1-dayou5941@163.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: _____wB37GlgfJpqs61iAg--.12312S2 X-Coremail-Antispam: 1Uf129KBjvdXoWrtF1Dury3uw4fXFyUKF4rZrb_yoWkJrc_Cr 48ur93GFWkCrnYyw4Y9r45Zr4UAFyqgFZIqF1v9FWay34qvr43XrnY9rn3Kr9rXrW8KFn8 GwnF9Fy3Aw1F9jkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IUbVHq3UUUUU== X-CM-SenderInfo: 5gd103ivzuiqqrwthudrp/xtbC+QJ4J2qafGKJQQAA3C X-Rspamd-Server: rspamd-worker-8404 X-Spamd-Result: default: False [4.84 / 15.00]; RBL_SENDERSCORE(2.00)[172.232.135.74:from]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; MAILLIST(-0.15)[generic]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; HAS_LIST_UNSUB(-0.01)[]; PRECEDENCE_BULK(0.00)[]; TAGGED_RCPT(0.00)[netdev]; RCPT_COUNT_TWELVE(0.00)[12]; DBL_BLOCKED_OPENRESOLVER(0.00)[sto.lore.kernel.org:rdns,sto.lore.kernel.org:helo,kylinos.cn:email]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[lunn.ch,davemloft.net,google.com,kernel.org,redhat.com,gmail.com,sholland.org,lists.linux.dev,lists.infradead.org,kylinos.cn]; R_DKIM_ALLOW(0.00)[163.com:s=s110527]; RCVD_COUNT_FIVE(0.00)[5]; FROM_NEQ_ENVFROM(0.00)[dayou5941@163.com,linux-sunxi@lists.linux.dev]; DKIM_TRACE(0.00)[163.com:+]; DMARC_POLICY_ALLOW(0.00)[163.com,none]; R_SPF_ALLOW(0.00)[+ip4:172.232.135.74]; FREEMAIL_FROM(0.00)[163.com]; FORGED_SENDER_MAILLIST(0.00)[]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[bounces-25562-noreply=patchwork.local]; ASN(0.00)[asn:63949, ipnet:172.232.128.0/19, country:SG]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: DCE721C0BF9 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
net: sun4i-emac: fix missing of_node_put() for phy_node
|
|
Commit Message
Li Youhong
Sept. 4, 2026, 8:07 a.m. UTC
From: Li Youhong <liyouhong@kylinos.cn> of_parse_phandle() returns a node pointer with an elevated refcount. Add the missing of_node_put() on the probe error path after register_netdev() fails and in emac_remove(). Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: Li Youhong <liyouhong@kylinos.cn> --- drivers/net/ethernet/allwinner/sun4i-emac.c | 2 ++ 1 file changed, 2 insertions(+)
Comments
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: Pre-existing issues: - [High] Unconditional call to `dma_release_channel()` with a potentially NULL pointer in the `emac_probe()` error path causes a kernel panic. - [High] Premature release of the DMA channel before `unregister_netdev()` in `emac_remove()` creates a use-after-free race condition. -- commit c4716a5c5ccd2a56d9acba6cfcd5d61c3d288e5f Author: Li Youhong <liyouhong@kylinos.cn> net: sun4i-emac: fix missing of_node_put() for phy_node This commit fixes a reference leak on the PHY node in the sun4i-emac driver. It adds the missing of_node_put() calls on the probe error path and during device removal to properly decrement the reference count elevated by of_parse_phandle(). > diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c > index 942454e294882..0ba67a55705d6 100644 > --- a/drivers/net/ethernet/allwinner/sun4i-emac.c > +++ b/drivers/net/ethernet/allwinner/sun4i-emac.c > @@ -1067,6 +1067,7 @@ static int emac_probe(struct platform_device *pdev) > return 0; > > out_release_sram: > + of_node_put(db->phy_node); > sunxi_sram_release(&pdev->dev); > out_clk_disable_unprepare: > clk_disable_unprepare(db->clk); [Severity: High] This is a pre-existing issue, but just below these lines in the error handling path of emac_probe(), the code calls: out_dispose_mapping: irq_dispose_mapping(ndev->irq); dma_release_channel(db->rx_chan); Can this unconditional call to dma_release_channel() cause a kernel panic due to a NULL pointer dereference? If emac_configure_dma() fails to acquire a DMA channel earlier in emac_probe(), it sets db->rx_chan to NULL and allows fallback to non-DMA mode. If a subsequent step like devm_clk_get() then fails, execution jumps to out_dispose_mapping and dereferences db->rx_chan without checking if it is NULL. > @@ -1094,6 +1095,7 @@ static void emac_remove(struct platform_device *pdev) > } > > unregister_netdev(ndev); > + of_node_put(db->phy_node); > sunxi_sram_release(&pdev->dev); > clk_disable_unprepare(db->clk); > irq_dispose_mapping(ndev->irq); [Severity: High] This is a pre-existing issue, but looking at the context right above this in emac_remove(): if (db->rx_chan) { dmaengine_terminate_all(db->rx_chan); dma_release_channel(db->rx_chan); } unregister_netdev(ndev); Does releasing the DMA channel before unregistering the network device create a use-after-free race condition? The network interface is still logically UP when dma_release_channel() is called, meaning its IRQ handler (emac_interrupt) is active until unregister_netdev() completes. If an incoming packet triggers a receive interrupt in this window, the handler calls emac_rx(), which checks if db->rx_chan is non-NULL. Since db->rx_chan is not cleared after release, would this submit a new DMA transaction using the freed channel structure?
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c +++ b/drivers/net/ethernet/allwinner/sun4i-emac.c @@ -1067,6 +1067,7 @@ static int emac_probe(struct platform_device *pdev) return 0; out_release_sram: + of_node_put(db->phy_node); sunxi_sram_release(&pdev->dev); out_clk_disable_unprepare: clk_disable_unprepare(db->clk); @@ -1094,6 +1095,7 @@ static void emac_remove(struct platform_device *pdev) } unregister_netdev(ndev); + of_node_put(db->phy_node); sunxi_sram_release(&pdev->dev); clk_disable_unprepare(db->clk); irq_dispose_mapping(ndev->irq);