[PATCH RESEND net-next] ptp: Limit time setting of PTP clocks

[PATCH RESEND net-next] ptp: Limit time setting of PTP clocks

[Miroslav Lichvar]

Networking drivers implementing PTP clocks and kernel socket code
handling hardware timestamps use the 64-bit signed ktime_t type counting
nanoseconds. When a PTP clock reaches the maximum value in year 2262,
the timestamps returned to applications will overflow into year 1667.
The same thing happens when injecting a large offset with
clock_adjtime(ADJ_SETOFFSET).

The commit 7a8e61f84786 ("timekeeping: Force upper bound for setting
CLOCK_REALTIME") limited the maximum accepted value setting the system
clock to 30 years before the maximum representable value (i.e. year
2232) to avoid the overflow, assuming the system will not run for more
than 30 years.

Enforce the same limit for PTP clocks. Don't allow negative values and
values closer than 30 years to the maximum value. Drivers may implement
an even lower limit if the hardware registers cannot represent the whole
interval between years 1970 and 2262 in the required resolution.

Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <jstultz@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
---

Notes:
    Original submission: https://lkml.org/lkml/2024/9/9/999

 drivers/ptp/ptp_clock.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index 1cc06b7cb17e..72cf00655391 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -100,6 +100,9 @@ static int ptp_clock_settime(struct posix_clock *pc, const struct timespec64 *tp
 		return -EBUSY;
 	}
 
+	if (!timespec64_valid_settod(tp))
+		return -EINVAL;
+
 	return  ptp->info->settime64(ptp->info, tp);
 }
 
@@ -130,7 +133,7 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct __kernel_timex *tx)
 	ops = ptp->info;
 
 	if (tx->modes & ADJ_SETOFFSET) {
-		struct timespec64 ts;
+		struct timespec64 ts, ts2;
 		ktime_t kt;
 		s64 delta;
 
@@ -140,7 +143,14 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct __kernel_timex *tx)
 		if (!(tx->modes & ADJ_NANO))
 			ts.tv_nsec *= 1000;
 
-		if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC)
+		/* Make sure the offset is valid */
+		err = ptp_clock_gettime(pc, &ts2);
+		if (err)
+			return err;
+		ts2 = timespec64_add(ts2, ts);
+
+		if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC ||
+		    !timespec64_valid_settod(&ts2))
 			return -EINVAL;
 
 		kt = timespec64_to_ktime(ts);
-- 
2.50.1

Re: [PATCH RESEND net-next] ptp: Limit time setting of PTP clocks

[Jakub Kicinski]

On Mon, 25 Aug 2025 13:11:13 +0200 Miroslav Lichvar wrote:
> -		if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC)
> +		/* Make sure the offset is valid */
> +		err = ptp_clock_gettime(pc, &ts2);
> +		if (err)
> +			return err;
> +		ts2 = timespec64_add(ts2, ts);
> +
> +		if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC ||
> +		    !timespec64_valid_settod(&ts2))
>  			return -EINVAL;

Please leave the input validation (tv_nsec >= NSEC_PER_SEC)
separate and before we call gettime. It's easy to miss that
on part of the condition is checking ts and the other ts2.

Do we not need to apply the same treatment to adjphase?
-- 
pw-bot: cr

Re: [PATCH RESEND net-next] ptp: Limit time setting of PTP clocks

[Miroslav Lichvar]

On Wed, Aug 27, 2025 at 05:37:08PM -0700, Jakub Kicinski wrote:
> On Mon, 25 Aug 2025 13:11:13 +0200 Miroslav Lichvar wrote:
> > -		if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC)
> > +		/* Make sure the offset is valid */
> > +		err = ptp_clock_gettime(pc, &ts2);
> > +		if (err)
> > +			return err;
> > +		ts2 = timespec64_add(ts2, ts);
> > +
> > +		if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC ||
> > +		    !timespec64_valid_settod(&ts2))
> >  			return -EINVAL;
> 
> Please leave the input validation (tv_nsec >= NSEC_PER_SEC)
> separate and before we call gettime. It's easy to miss that
> on part of the condition is checking ts and the other ts2.

Ok, I'll send a v2.

> Do we not need to apply the same treatment to adjphase?

No, those phase adjustments are very small (sub-second) and slow. They
don't cause a step in time, only the frequency. The value is already
checked against the maximum provided by the driver.

Thanks,

-- 
Miroslav Lichvar