[PATCH net] net: stmmac: dwmac-rk: Ensure clk_phy doesn't contain invalid address
Simon Horman
horms at kernel.org
Thu Sep 4 03:28:45 PDT 2025
On Thu, Sep 04, 2025 at 10:10:01AM +0000, Yao Zi wrote:
> On Thu, Sep 04, 2025 at 10:56:57AM +0100, Simon Horman wrote:
> > On Thu, Sep 04, 2025 at 10:54:57AM +0100, Simon Horman wrote:
> > > On Thu, Sep 04, 2025 at 03:12:24AM +0000, Yao Zi wrote:
> > > > We must set the clk_phy pointer to NULL to indicating it isn't available
> > > > if the optional phy clock couldn't be obtained. Otherwise the error code
> > > > returned by of_clk_get() could be wrongly taken as an address, causing
> > > > invalid pointer dereference when later clk_phy is passed to
> > > > clk_prepare_enable().
> > > >
> > > > Fixes: da114122b831 ("net: ethernet: stmmac: dwmac-rk: Make the clk_phy could be used for external phy")
> > > > Signed-off-by: Yao Zi <ziyao at disroot.org>
> > >
> > > ...
> > >
> > > Hi,
> > >
> > > I this patch doesn't seem to match upstream code.
> > >
> > > Looking over the upstream code, it seems to me that
> > > going into the code in question .clk_phy should
> > > be NULL, as bsp_priv it is allocated using devm_kzalloc()
> > > over in rk_gmac_setup()
> > >
> > > While the upstream version of the code your patch modifies
> > > is as follows. And doesn't touch .clk_phy if integrated_phy is not set.
> > >
> > > if (plat->phy_node && bsp_priv->integrated_phy) {
> > > bsp_priv->clk_phy = of_clk_get(plat->phy_node, 0);
> > > ret = PTR_ERR_OR_ZERO(bsp_priv->clk_phy);
> > > if (ret)
> > > return dev_err_probe(dev, ret, "Cannot get PHY clock\n");
> > > clk_set_rate(bsp_priv->clk_phy, 50000000);
> > > }
> > >
> > > Am I missing something?
> >
> > Oops, I missed that da114122b831 is present in net-next (but not net).
> > Let me look over this a second time.
>
> Oops, yes. Though this is a fix patch, it should target net-next instead
> of net since the commit causing problems hasn't landed in net. Sorry for
> the confusion.
It's ok. I'm pretty good at confusing myself without any assistance.
More information about the linux-arm-kernel
mailing list