Re: [PATCH net v1] net: ravb: fix use-after-free in ravb_get_ts_info

["Niklas Söderlund" <niklas.soderlund@ragnatech.se>]

Hello Xuanqiang,

On 2026-08-01 09:56:30 +0800, luoxuanqiang wrote:
> 
> 在 2026/8/1 02:25, Niklas Söderlund 写道:
> > Hello Xuanqiang,
> > 
> > Thanks for your work.
> > 
> > On 2026-07-31 14:32:54 +0800, xuanqiang.luo@linux.dev wrote:
> > > From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
> > > 
> > > The PHC is registered by ravb_open() and unregistered by ravb_close().
> > > However, ravb_ptp_stop() leaves priv->ptp.clock pointing at the freed
> > > clock. Since the netdev remains registered after ndo_stop, get_ts_info
> > > can still pass the dangling pointer to ptp_clock_index(), resulting in a
> > > use-after-free.
> > > 
> > > Clear the pointer after unregistering the clock and only query the index
> > > while a clock is registered.
> > > 
> > > Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
> > > ---
> > > I don't have access to RAVB hardware to reproduce the issue. To aid
> > > review, see the similar PHC lifetime fix merged as commit 8da13e6d63c1
> > > ("net: macb: fix use-after-free access to PTP clock").
> > > 
> > >   drivers/net/ethernet/renesas/ravb_main.c | 3 ++-
> > >   drivers/net/ethernet/renesas/ravb_ptp.c  | 5 ++++-
> > >   2 files changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> > > index 5f88733094d0f..3a9d9f8718216 100644
> > > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > > @@ -1779,7 +1779,8 @@ static int ravb_get_ts_info(struct net_device *ndev,
> > >   			(1 << HWTSTAMP_FILTER_NONE) |
> > >   			(1 << HWTSTAMP_FILTER_PTP_V2_L2_EVENT) |
> > >   			(1 << HWTSTAMP_FILTER_ALL);
> > > -		info->phc_index = ptp_clock_index(priv->ptp.clock);
> > > +		if (priv->ptp.clock)
> > > +			info->phc_index = ptp_clock_index(priv->ptp.clock);
> > While this avoids the lifetime issue, the fix is incomplete. The info
> > structure will still report HW clock support but there is no PTP clock
> > index.
> > 
> > I have a pending series which cleans up most, if not all, of this issue.
> > Could you check [1] and see if that covers your concern? I will post a
> > new version of that series as soon as vacation time is over and the Gen4
> > PTP driver itself is merged.
> > 
> > 1.  https://lore.kernel.org/all/20260610102432.3538432-1-niklas.soderlund+renesas@ragnatech.se/
> > 
> Hello Niklas,
> 
> Thanks for taking the time to reply while on vacation.
> 
> You are right that my current patch is incomplete: it fills in the
> hardware timestamping capabilities before checking priv->ptp.clock.
> 
> This should be straightforward to fix:
> @@
> -    if (hw_info->gptp || hw_info->ccc_gac) {
> +    if ((hw_info->gptp || hw_info->ccc_gac) &&
> +        priv->ptp.clock) {
>          ...
> -        if (priv->ptp.clock)
> -            info->phc_index = ptp_clock_index(priv->ptp.clock);
> +        info->phc_index = ptp_clock_index(priv->ptp.clock);
>      }
> 
> I also checked patch 7/9 of your series. In the currently posted
> version, ravb_ptp_stop() still does not clear priv->ptp.clock after
> unregistering the PHC, while ravb_gen2_ptp_clock_index() calls
> ptp_clock_index(priv->ptp.clock) unconditionally. Therefore, as
> currently posted, the series does not appear to fully cover the UAF for
> the Gen2/Gen3 paths.
> 
> As this issue predates the Gen4 work, if you agree that a small
> standalone patch would be useful for fixing the UAF in stable kernels,
> I would be happy to send a v2 including the change above.

Ahh, yes you are correct. Clearing priv->ptp.clock after the clock have 
been unregistered, and checking it before use, is not introduced in that 
series. And as you do here that should be fixed.

I have no strong opinion if this is done before or after the PTP rework 
series. If you want to send a v2 and have it go in before I will rebase 
on top of your work. Else adding this on-top of the rework is trivial as 
the locations where it needs to be checked are abstracted out to  
callbacks.

> 
> Enjoy your vacation!
> 
> Best regards,
> Xuanqiang
> 

-- 
Kind Regards,
Niklas Söderlund