Re: [PATCH] ptp: guard ptp_clock_gettime() if neither gettimex64 nor

[Vadim Fedorenko]

On 28.10.2025 23:54, Kuniyuki Iwashima wrote:
> On Tue, Oct 28, 2025 at 4:45 PM Vadim Fedorenko
> <vadim.fedorenko@xxxxxxxxx> wrote:
> > On 28.10.2025 23:13, Jakub Kicinski wrote:
> > > On Tue, 28 Oct 2025 15:51:50 +0000 Kuniyuki Iwashima wrote:
> > > > From: Richard Cochran <richardcochran@xxxxxxxxx>
> > > > Date: Tue, 28 Oct 2025 07:09:41 -0700
> > > > > On Tue, Oct 28, 2025 at 05:51:43PM +0800, Junjie Cao wrote:
> > > > > > Syzbot reports a NULL function pointer call on arm64 when
> > > > > > ptp_clock_gettime() falls back to ->gettime64() and the driver provides
> > > > > > neither ->gettimex64() nor ->gettime64(). This leads to a crash in the
> > > > > > posix clock gettime path.
> > > > >
> > > > > Drivers must provide a gettime method.
> > > > >
> > > > > If they do not, then that is a bug in the driver.
> > > >
> > > > AFAICT, only GVE does not have gettime() and settime(), and
> > > > Tim (CCed) was preparing a fix and mostly ready to post it.
> > >
> > > cc: Vadim who promised me a PTP driver test :) Let's make sure we
> > > tickle gettime/setting in that test..
> >
> > Heh, call gettime/settime is easy. But in case of absence of these callbacks
> > the kernel will crash - not sure we can gather good signal in such case?
>
> At least we could catch it on NIPA.
>
> but I suggested Tim adding WARN_ON_ONCE(!info->gettime64 &&
> !info-> getimex64) in ptp_clock_register() so that a developer can
> notice that even while loading a buggy module.

Yeah, that looks like a solution