[PATCH v4 phy-next 01/16] phy: lynx-28g: avoid returning NULL in of_xlate() function

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] A concurrent unbind of the PHY provider can cause a Use-After-Free when accessing the `phy` pointer in `of_phy_get()`.
--

commit 33b5ab7917964ed203a6c538e1528b54f76fa1e5
Author: Vladimir Oltean <vladimir.oltean at nxp.com>

phy: lynx-28g: avoid returning NULL in of_xlate() function

Sashiko points out that _of_phy_get() does not support a NULL returned
output from phy_provider->of_xlate(), just a valid pointer or a
pointer-encoded error.

> diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> --- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
> +++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> @@ -1435,7 +1435,7 @@ static struct phy *lynx_28g_xlate(struct device *dev,
>  		    idx < priv->info->first_lane))
>  		return ERR_PTR(-EINVAL);
>  
> -	return priv->lane[idx].phy;
> +	return priv->lane[idx].phy ?: ERR_PTR(-ENODEV);
>  }

[Severity: High]
This is a pre-existing issue, but looking at how the xlate callbacks are
consumed in the PHY core, could there be a use-after-free race condition
during device unbind?

In drivers/phy/phy-core.c:of_phy_get(), the provider's xlate callback is 
invoked via _of_phy_get():

	phy = _of_phy_get(np, index);
	if (IS_ERR(phy))
		return phy;

	if (!try_module_get(phy->ops->owner))
		return ERR_PTR(-EPROBE_DEFER);

	get_device(&phy->dev);

Since _of_phy_get() drops the phy_provider_mutex before returning the raw,
unreferenced phy pointer, what prevents a concurrent unbind of the PHY
provider from freeing the phy memory before the pointer is dereferenced via
phy->ops->owner? 

If the provider is unregistered (e.g., via sysfs) and phy_destroy() drops
the PHY device's reference count to zero precisely after _of_phy_get()
returns, would this result in accessing freed memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608221710.1572971-1-vladimir.oltean@nxp.com?part=1