Re: [PATCH net v1] net: ravb: fix use-after-free in ravb_get_ts_info
Niklas Söderlund <[email protected]> Sat, 1 Aug 2026 11:35:32 +0200
| Newsgroups | org.kernel.vger.linux-renesas-soc,org.kernel.vger.netdev,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
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, [email protected] wrote: > > > From: Xuanqiang Luo <[email protected]> > > > > > > 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: [email protected] > > > Signed-off-by: Xuanqiang Luo <[email protected]> > > > --- > > > 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/[email protected]/ > > > 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