Re: [PATCH] net: lpc_eth: Fix a possible memory leak in lpc_mii_probe()

[Vladimir Zapolskiy]

Hello Ma Ke.

On 4/1/26 16:18, Ma Ke wrote:
> On 3/30/26 13:04, Vladimir Zapolskiy wrote:
> > On 3/30/26 11:16, Ma Ke wrote:
> > > lpc_mii_probe() calls of_phy_find_device() to obtain a phy_device
> > > pointer. of_phy_find_device() increments the refcount of the device.
> > > The current implementation does not decrement the refcount after using
> > > the pointer, which leads to a memory leak.
> >
> > this is correct, there is an actual detected bug.
> >
> > > Add phy_device_free() to balance the refcount.
> >
> > But this does not sound right, you shoud use of_node_put(pldat->phy_node).
> >
> > > Found by code review.
> > >
> > > Signed-off-by: Ma Ke <make24@xxxxxxxxxxx>
> > > Cc: stable@xxxxxxxxxxxxxxx
> > > Fixes: 3503bf024b3e ("net: lpc_eth: parse phy nodes from device tree")
> > > ---
> > >    drivers/net/ethernet/nxp/lpc_eth.c | 11 ++++++-----
> > >    1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> > > index 8b9a3e3bba30..8ce7c9bb6dd6 100644
> > > --- a/drivers/net/ethernet/nxp/lpc_eth.c
> > > +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> > > @@ -751,7 +751,7 @@ static void lpc_handle_link_change(struct net_device *ndev)
> > >    static int lpc_mii_probe(struct net_device *ndev)
> > >    {
> > >    	struct netdata_local *pldat = netdev_priv(ndev);
> > > -	struct phy_device *phydev;
> > > +	struct phy_device *phydev, *phydev_tmp;
> > >    
> > >    	/* Attach to the PHY */
> > >    	if (lpc_phy_interface_mode(&pldat->pdev->dev) == PHY_INTERFACE_MODE_MII)
> > > @@ -760,17 +760,18 @@ static int lpc_mii_probe(struct net_device *ndev)
> > >    		netdev_info(ndev, "using RMII interface\n");
> > >    
> > >    	if (pldat->phy_node)
> > > -		phydev =  of_phy_find_device(pldat->phy_node);
> > > +		phydev_tmp =  of_phy_find_device(pldat->phy_node);
> > >    	else
> > > -		phydev = phy_find_first(pldat->mii_bus);
> > > -	if (!phydev) {
> > > +		phydev_tmp = phy_find_first(pldat->mii_bus);
> > > +	if (!phydev_tmp) {
> >
> > I didn't get it, why the new phydev_tmp is needed above, please
> > restore the original code above.
> >
> > >    		netdev_err(ndev, "no PHY found\n");
> > >    		return -ENODEV;
> > >    	}
> > >    
> > > -	phydev = phy_connect(ndev, phydev_name(phydev),
> > > +	phydev = phy_connect(ndev, phydev_name(phydev_tmp),
> > >    			     &lpc_handle_link_change,
> > >    			     lpc_phy_interface_mode(&pldat->pdev->dev));
> > > +	phy_device_free(phydev_tmp);
> >
> > This is plainly wrong and has to be dropped or changed to
> >
> > 	if (pldat->phy_node)
> > 		of_node_put(pldat->phy_node);
> >
> > >    	if (IS_ERR(phydev)) {
> > >    		netdev_err(ndev, "Could not attach to PHY\n");
> > >    		return PTR_ERR(phydev);
> >
> > Is it AI generated fix or what?.. The change looks bad, it introduces
> > more severe issues than it fixes.
> >
> > If you think you cannot create a proper change, let me know.
> Thank you very much for your detailed review and guidance.
>
> Now I think your point probably is: you are saying that the real leak
> is not from of_phy_find_device(), but from the device node

I was pretty indelicate in my comment, let's split the change into parts.

1) I still do not understand, why phydev_tmp is introduced, please explain
or remove this part of the change;

2) phydev = of_phy_find_device() requires phy_device_free(phydev), but
I do not see why phy_find_first() requires it, while it was added in your
change.

Let's start from resolving these two points.

> pldat->phy_node which was obtained earlier (probably by
> of_parse_phandle()) and never freed by of_node_put(). And you suggest
> to add of_node_put(pldat->phy_node) instead of my wrong
> phy_device_free().
>
> However, I am still a little confused. In lpc_mii_probe(),
> of_phy_find_device() is called. From my understanding, this function
> increases the reference count of the device. To balance it, I thought
> phy_device_free() (which calls put_device()) should be used.
>
> Could you please kindly advise the correct patch? I will follow your
> guidance and submit a proper fix.
>
> I apologize again for my previous wrong patch. Thank you very much for
> your help.

--
Best wishes,
Vladimir