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

[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+c8c0e7ccabd456541612@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c8c0e7ccabd456541612
Signed-off-by: Junjie Cao <junjie.cao@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

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

[Pavan Chebbi]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

On Tue, Oct 28, 2025 at 3:22 PM Junjie Cao <junjie.cao@intel.com> 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.
>
> Return -EOPNOTSUPP when both callbacks are missing, avoiding the crash
> and matching the defensive style used in the posix clock layer.
>
> Reported-by: syzbot+c8c0e7ccabd456541612@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=c8c0e7ccabd456541612
> Signed-off-by: Junjie Cao <junjie.cao@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;
>  }

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
>
>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]

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

[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

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

[Kuniyuki Iwashima]

From: Richard Cochran <richardcochran@gmail.com>
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.

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

[Jakub Kicinski]

On Tue, 28 Oct 2025 15:51:50 +0000 Kuniyuki Iwashima wrote:
> From: Richard Cochran <richardcochran@gmail.com>
> 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..

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

[Vadim Fedorenko]

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@gmail.com>
>> 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?

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

[Kuniyuki Iwashima]

On Tue, Oct 28, 2025 at 4:45 PM Vadim Fedorenko
<vadim.fedorenko@linux.dev> 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@gmail.com>
> >> 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.

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

[Kuniyuki Iwashima]

On Tue, Oct 28, 2025 at 4:54 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
>
> On Tue, Oct 28, 2025 at 4:45 PM Vadim Fedorenko
> <vadim.fedorenko@linux.dev> 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@gmail.com>
> > >> 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.

Of course this needs to check settime too.

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@linux.dev> 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@gmail.com>
>>>> 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

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

[Tim Hostetler]

On Tue, Oct 28, 2025 at 4:57 PM Vadim Fedorenko
<vadim.fedorenko@linux.dev> wrote:
>
> On 28.10.2025 23:54, Kuniyuki Iwashima wrote:
> > On Tue, Oct 28, 2025 at 4:45 PM Vadim Fedorenko
> > <vadim.fedorenko@linux.dev> 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@gmail.com>
> >>>> 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

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.

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

[Vadim Fedorenko]

On 29/10/2025 16:37, Tim Hostetler wrote:
> On Tue, Oct 28, 2025 at 4:57 PM Vadim Fedorenko
> <vadim.fedorenko@linux.dev> wrote:
>>
>> On 28.10.2025 23:54, Kuniyuki Iwashima wrote:
>>> On Tue, Oct 28, 2025 at 4:45 PM Vadim Fedorenko
>>> <vadim.fedorenko@linux.dev> 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@gmail.com>
>>>>>> 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
> 
> 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.