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

[Junjie Cao]

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.

Return -EOPNOTSUPP when both callbacks are missing, avoiding the crash
and matching the defensive style used in the posix clock layer.

Reported-by: syzbot+c8c0e7...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c8c0e7ccabd456541612
Signed-off-by: Junjie Cao <junji...@intel.com>
---
drivers/ptp/ptp_clock.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index ef020599b771..764bd25220c1 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -110,12 +110,14 @@ static int ptp_clock_settime(struct posix_clock *pc, const struct timespec64 *tp
static int ptp_clock_gettime(struct posix_clock *pc, struct timespec64 *tp)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
- int err;
+ int err = -EOPNOTSUPP;

if (ptp->info->gettimex64)
- err = ptp->info->gettimex64(ptp->info, tp, NULL);
- else
- err = ptp->info->gettime64(ptp->info, tp);
+ return ptp->info->gettimex64(ptp->info, tp, NULL);
+
+ if (ptp->info->gettime64)
+ return ptp->info->gettime64(ptp->info, tp);
+
return err;
}

--
2.43.0

[Pavan Chebbi]

Patch looks valid to me. But a similar situation exists right above
this function where ptp_clock_settime() is calling
ptp->info->settime64() unconditionally.
Maybe that can be guarded also?
Also this looks like a patch meant for "net" with an improved title IMO.

>
> --
> 2.43.0
>
>

[Richard Cochran]

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.

Thanks,
Richard

[Kuniyuki Iwashima]

From: Richard Cochran <richard...@gmail.com>
Date: Tue, 28 Oct 2025 07:09:41 -0700

AFAICT, only GVE does not have gettime() and settime(), and
Tim (CCed) was preparing a fix and mostly ready to post it.

[Jakub Kicinski]

cc: Vadim who promised me a PTP driver test :) Let's make sure we
tickle gettime/setting in that test..

[Vadim Fedorenko]

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?

[Kuniyuki Iwashima]

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.

[Kuniyuki Iwashima]

Of course this needs to check settime too.

[Vadim Fedorenko]

Yeah, that looks like a solution

[Vadim Fedorenko]

On 29/10/2025 16:37, Tim Hostetler wrote:
> On Tue, Oct 28, 2025 at 4:57 PM Vadim Fedorenko

> Yes, I was actually going to post the fix to gve today (I'll still do
> that as ptp_clock_gettime() is not the only function to assume a
> gettime64 or gettimex64 implementation) and shortly after posting
> Kuniyuki's suggested fix to ptp_clock_register() as such:
>
> diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
> index ef020599b771..f2d9cf4a455e 100644
> --- a/drivers/ptp/ptp_clock.c
> +++ b/drivers/ptp/ptp_clock.c
> @@ -325,6 +325,9 @@ struct ptp_clock *ptp_clock_register(struct
> ptp_clock_info *info,
> if (info->n_alarm > PTP_MAX_ALARMS)
> return ERR_PTR(-EINVAL);
>
> + if (WARN_ON_ONCE(!info->gettimex64 && !info->gettime64))
> + return ERR_PTR(-EINVAL);
> +
> /* Initialize a clock structure. */
> ptp = kzalloc(sizeof(struct ptp_clock), GFP_KERNEL);
> if (!ptp) {
> --
>
> I also have a similar patch for checking for settime64's function pointer.
>
> But I have no objections to Junjie posting a v2 in this manner instead
> of waiting for me.

WARN_ON_ONCE is better in terms of reducing the amount of review work.
Driver developers will be automatically notified about improper
implementation while Junjie's patch will simply hide the problem.

[Tim Hostetler]

On Tue, Oct 28, 2025 at 4:57 PM Vadim Fedorenko