[PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

[PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

[wei.fang]

From: Wei Fang <wei.fang@nxp.com>

The max_period bound in net_timer_enable_perout() was computed as:

  max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;

which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for
the default 333333333 Hz clock). A period_ns that passes this check but
exceeds U32_MAX is then silently truncated when stored into the u32
struct netc_pp::period field.

A truncated value of zero can reach netc_timer_set_perout_alarm(), where
the local u32 period variable would also be 0, causing a divide-by-zero
in roundup_u64(delta, period) whenever the stime < min_time branch is
taken (which always happens for a start time of {0, 0}).

Additionally, netc_timer_enable_periodic_pulse() and
netc_timer_enable_fiper() both compute:

  fiper = pp->period - integral_period;

A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD,
mis-programming the FIPER hardware register.

Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER
(0xFFFFFFFF). This ensures that any period_ns passing the range check
fits in a u32 without truncation, so the stored value is always valid
and non-zero. The accepted range is reduced by integral_period ns
(typically only a few nanoseconds), which is negligible in practice.

Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 drivers/ptp/ptp_netc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ptp/ptp_netc.c b/drivers/ptp/ptp_netc.c
index 59db08e189e6..05d606e636b1 100644
--- a/drivers/ptp/ptp_netc.c
+++ b/drivers/ptp/ptp_netc.c
@@ -450,7 +450,7 @@ static int net_timer_enable_perout(struct netc_timer *priv,
 		period_ns = timespec64_to_ns(&period);
 
 		integral_period = netc_timer_get_integral_period(priv);
-		max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
+		max_period = NETC_TMR_DEFAULT_FIPER;
 		gclk_period = netc_timer_get_gclk_period(priv);
 		min_period = gclk_period * 4 + integral_period;
 		if (period_ns > max_period || period_ns < min_period) {
-- 
2.34.1

Re: [PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Division by zero in `roundup_u64()` when `integral_period` evaluates to 0 due to clock frequency adjustments.
- [Medium] Missing validation of `clk_get_rate()` allows a division by zero if the reference clock rate is 0.
--

--- Patch [1]: [PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT ---
commit 29d635c27b8bca8b216f11e24d3881ee5aec72c6
Author: Wei Fang <wei.fang@nxp.com>

ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

This commit caps max_period at NETC_TMR_DEFAULT_FIPER to prevent a period
truncation bug in net_timer_enable_perout() that causes silent truncation
and potential divide-by-zero issues in PEROUT.

> diff --git a/drivers/ptp/ptp_netc.c b/drivers/ptp/ptp_netc.c
> index 59db08e189e6e..05d606e636b1a 100644
> --- a/drivers/ptp/ptp_netc.c
> +++ b/drivers/ptp/ptp_netc.c
> @@ -450,7 +450,7 @@ static int net_timer_enable_perout(struct netc_timer *priv,
>  		period_ns = timespec64_to_ns(&period);
>  
>  		integral_period = netc_timer_get_integral_period(priv);
> -		max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
> +		max_period = NETC_TMR_DEFAULT_FIPER;
>  		gclk_period = netc_timer_get_gclk_period(priv);
>  		min_period = gclk_period * 4 + integral_period;
>  		if (period_ns > max_period || period_ns < min_period) {

[Severity: High]
This isn't a bug introduced by this patch, but can a zero integral_period
trigger a divide-by-zero panic in roundup_u64()?

Looking at netc_timer_set_pps_alarm() and netc_timer_set_perout_alarm():

drivers/ptp/ptp_netc.c:netc_timer_set_pps_alarm() {
	...
	alarm = netc_timer_cur_time_read(priv) +  NSEC_PER_MSEC;
	alarm = roundup_u64(alarm, NSEC_PER_SEC);
	alarm = roundup_u64(alarm, integral_period);
	...
}

drivers/ptp/ptp_netc.c:netc_timer_set_perout_alarm() {
	...
	alarm = roundup_u64(stime - period, integral_period);
	netc_timer_alarm_write(priv, alarm, pp->alarm_id);
}

If the hardware clock frequency is fast enough (e.g., 600 MHz, giving a base
period of 1.666 ns), a large negative adjustment (e.g., -40% or -400,000,000
ppb) during a PTP adjfine ioctl will reduce the new_period below 1.0 ns.

When this happens, upper_32_bits(new_period) evaluates to 0, setting the
integral_period to 0.

netc_timer_adjust_period() then disables and re-enables the FIPER hardware,
invoking netc_timer_enable_fiper(), which sequentially calls
netc_timer_set_pps_alarm() and netc_timer_set_perout_alarm().

Since roundup_u64() performs a division via DIV_U64_ROUND_UP, passing 0
causes an immediate kernel panic. This path is reachable via the standard
PTP adjfine ioctl by userspace processes with CAP_SYS_TIME.

[Severity: Medium]
This is a pre-existing issue, but does this code validate the return value
from clk_get_rate()?

drivers/ptp/ptp_netc.c:netc_timer_get_reference_clk_source() {
	...
		if (clk) {
			priv->clk_freq = clk_get_rate(clk);
			priv->clk_select = i ? NETC_TMR_EXT_OSC :
					       NETC_TMR_CCM_TIMER1;
			break;
		}
	}

	/* The period is a 64-bit number, the high 32-bit is the integer
	 * part of the period, the low 32-bit is the fractional part of
	 * the period. In order to get the desired 32-bit fixed-point
	 * format, multiply the numerator of the fraction by 2^32.
	 */
	priv->period = div_u64((u64)NSEC_PER_SEC << 32, priv->clk_freq);
	...
}

If the clock is misconfigured or specified as a dummy clock in the device tree,
clk_get_rate() returns 0.

Passing 0 as the divisor to div_u64() will trigger an unhandled divide-by-zero
exception during the driver's probe sequence.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818033342.3154990-1-wei.fang@oss.nxp.com?part=1

Re: [PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

[Simon Horman]

On Tue, Aug 18, 2026 at 11:33:41AM +0800, wei.fang@oss.nxp.com wrote:
> From: Wei Fang <wei.fang@nxp.com>
> 
> The max_period bound in net_timer_enable_perout() was computed as:
> 
>   max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
> 
> which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for
> the default 333333333 Hz clock). A period_ns that passes this check but
> exceeds U32_MAX is then silently truncated when stored into the u32
> struct netc_pp::period field.
> 
> A truncated value of zero can reach netc_timer_set_perout_alarm(), where
> the local u32 period variable would also be 0, causing a divide-by-zero
> in roundup_u64(delta, period) whenever the stime < min_time branch is
> taken (which always happens for a start time of {0, 0}).
> 
> Additionally, netc_timer_enable_periodic_pulse() and
> netc_timer_enable_fiper() both compute:
> 
>   fiper = pp->period - integral_period;
> 
> A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD,
> mis-programming the FIPER hardware register.
> 
> Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER
> (0xFFFFFFFF). This ensures that any period_ns passing the range check
> fits in a u32 without truncation, so the stored value is always valid
> and non-zero. The accepted range is reduced by integral_period ns
> (typically only a few nanoseconds), which is negligible in practice.
> 
> Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support")
> Signed-off-by: Wei Fang <wei.fang@nxp.com>

If so, then I think NETC_TMR_DEFAULT_FIPER can simply be used in
place of max_period.

Something like this (completely untested!):

diff --git a/drivers/ptp/ptp_netc.c b/drivers/ptp/ptp_netc.c
index 28889b7b3e15..66d1f0532585 100644
--- a/drivers/ptp/ptp_netc.c
+++ b/drivers/ptp/ptp_netc.c
@@ -434,22 +434,22 @@
 	}

 	if (on) {
-		u64 period_ns, gclk_period, max_period, min_period;
+		u64 period_ns, gclk_period, min_period;
 		struct timespec64 period, stime;
 		u32 integral_period;
 		int alarm_id;

 		period.tv_sec = rq->perout.period.sec;
 		period.tv_nsec = rq->perout.period.nsec;
 		period_ns = timespec64_to_ns(&period);

 		integral_period = netc_timer_get_integral_period(priv);
-		max_period = NETC_TMR_DEFAULT_FIPER;
 		gclk_period = netc_timer_get_gclk_period(priv);
 		min_period = gclk_period * 4 + integral_period;
-		if (period_ns > max_period || period_ns < min_period) {
+		if (period_ns > NETC_TMR_DEFAULT_FIPER ||
+                   period_ns < min_period) {
 			dev_err(dev, "The period range is %llu ~ %lu\n",
-				min_period, max_period);
+				min_period, NETC_TMR_DEFAULT_FIPER);
 			err = -EINVAL;
 			goto unlock_spinlock;
 		}

RE: [PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

[Wei Fang]

NXP Confidential
> On Tue, Aug 18, 2026 at 11:33:41AM +0800, wei.fang@oss.nxp.com wrote:
> > From: Wei Fang <wei.fang@nxp.com>
> >
> > The max_period bound in net_timer_enable_perout() was computed as:
> >
> >   max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
> >
> > which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for
> > the default 333333333 Hz clock). A period_ns that passes this check but
> > exceeds U32_MAX is then silently truncated when stored into the u32
> > struct netc_pp::period field.
> >
> > A truncated value of zero can reach netc_timer_set_perout_alarm(), where
> > the local u32 period variable would also be 0, causing a divide-by-zero
> > in roundup_u64(delta, period) whenever the stime < min_time branch is
> > taken (which always happens for a start time of {0, 0}).
> >
> > Additionally, netc_timer_enable_periodic_pulse() and
> > netc_timer_enable_fiper() both compute:
> >
> >   fiper = pp->period - integral_period;
> >
> > A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD,
> > mis-programming the FIPER hardware register.
> >
> > Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER
> > (0xFFFFFFFF). This ensures that any period_ns passing the range check
> > fits in a u32 without truncation, so the stored value is always valid
> > and non-zero. The accepted range is reduced by integral_period ns
> > (typically only a few nanoseconds), which is negligible in practice.
> >
> > Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support")
> > Signed-off-by: Wei Fang <wei.fang@nxp.com>
>
> If so, then I think NETC_TMR_DEFAULT_FIPER can simply be used in
> place of max_period.

Yes, I also considered this modification, but ultimately chose this lazy
approach. Since you brought it up, I will improve it in the next version.
Thanks. :)

>
> Something like this (completely untested!):
>
> diff --git a/drivers/ptp/ptp_netc.c b/drivers/ptp/ptp_netc.c
> index 28889b7b3e15..66d1f0532585 100644
> --- a/drivers/ptp/ptp_netc.c
> +++ b/drivers/ptp/ptp_netc.c
> @@ -434,22 +434,22 @@
>       }
>
>       if (on) {
> -             u64 period_ns, gclk_period, max_period, min_period;
> +             u64 period_ns, gclk_period, min_period;
>               struct timespec64 period, stime;
>               u32 integral_period;
>               int alarm_id;
>
>               period.tv_sec = rq->perout.period.sec;
>               period.tv_nsec = rq->perout.period.nsec;
>               period_ns = timespec64_to_ns(&period);
>
>               integral_period = netc_timer_get_integral_period(priv);
> -             max_period = NETC_TMR_DEFAULT_FIPER;
>               gclk_period = netc_timer_get_gclk_period(priv);
>               min_period = gclk_period * 4 + integral_period;
> -             if (period_ns > max_period || period_ns < min_period) {
> +             if (period_ns > NETC_TMR_DEFAULT_FIPER ||
> +                   period_ns < min_period) {
>                       dev_err(dev, "The period range is %llu ~ %lu\n",
> -                             min_period, max_period);
> +                             min_period, NETC_TMR_DEFAULT_FIPER);
>                       err = -EINVAL;
>                       goto unlock_spinlock;
>               }

Re: [PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

[Abel Vesa]

On 26-08-21 01:52:37, Wei Fang wrote:
> 
> NXP Confidential

Which part is confidential ?

> > On Tue, Aug 18, 2026 at 11:33:41AM +0800, wei.fang@oss.nxp.com wrote:
> > > From: Wei Fang <wei.fang@nxp.com>
> > >
> > > The max_period bound in net_timer_enable_perout() was computed as:
> > >
> > >   max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
> > >
> > > which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for
> > > the default 333333333 Hz clock). A period_ns that passes this check but
> > > exceeds U32_MAX is then silently truncated when stored into the u32
> > > struct netc_pp::period field.
> > >
> > > A truncated value of zero can reach netc_timer_set_perout_alarm(), where
> > > the local u32 period variable would also be 0, causing a divide-by-zero
> > > in roundup_u64(delta, period) whenever the stime < min_time branch is
> > > taken (which always happens for a start time of {0, 0}).
> > >
> > > Additionally, netc_timer_enable_periodic_pulse() and
> > > netc_timer_enable_fiper() both compute:
> > >
> > >   fiper = pp->period - integral_period;
> > >
> > > A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD,
> > > mis-programming the FIPER hardware register.
> > >
> > > Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER
> > > (0xFFFFFFFF). This ensures that any period_ns passing the range check
> > > fits in a u32 without truncation, so the stored value is always valid
> > > and non-zero. The accepted range is reduced by integral_period ns
> > > (typically only a few nanoseconds), which is negligible in practice.
> > >
> > > Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support")
> > > Signed-off-by: Wei Fang <wei.fang@nxp.com>
> >
> > If so, then I think NETC_TMR_DEFAULT_FIPER can simply be used in
> > place of max_period.
> 
> Yes, I also considered this modification, but ultimately chose this lazy
> approach. Since you brought it up, I will improve it in the next version.
> Thanks. :)

Hopefully, not the lazy part. ;-)

RE: [PATCH net] ptp: netc: fix period truncation and potential divide-by-zero in PEROUT

[Wei Fang]

> 
> On 26-08-21 01:52:37, Wei Fang wrote:
> >
> > NXP Confidential
> 
> Which part is confidential ?

Sorry, the company's email policy has been updated, and this label needs
to be manually deleted, but I didn't notice. :(


> 
> > > On Tue, Aug 18, 2026 at 11:33:41AM +0800, wei.fang@oss.nxp.com wrote:
> > > > From: Wei Fang <wei.fang@nxp.com>
> > > >
> > > > The max_period bound in net_timer_enable_perout() was computed as:
> > > >
> > > >   max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
> > > >
> > > > which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002
> > > > for the default 333333333 Hz clock). A period_ns that passes this
> > > > check but exceeds U32_MAX is then silently truncated when stored
> > > > into the u32 struct netc_pp::period field.
> > > >
> > > > A truncated value of zero can reach netc_timer_set_perout_alarm(),
> > > > where the local u32 period variable would also be 0, causing a
> > > > divide-by-zero in roundup_u64(delta, period) whenever the stime <
> > > > min_time branch is taken (which always happens for a start time of {0, 0}).
> > > >
> > > > Additionally, netc_timer_enable_periodic_pulse() and
> > > > netc_timer_enable_fiper() both compute:
> > > >
> > > >   fiper = pp->period - integral_period;
> > > >
> > > > A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD,
> > > > mis-programming the FIPER hardware register.
> > > >
> > > > Fix all three issues by capping max_period at
> > > > NETC_TMR_DEFAULT_FIPER (0xFFFFFFFF). This ensures that any
> > > > period_ns passing the range check fits in a u32 without
> > > > truncation, so the stored value is always valid and non-zero. The
> > > > accepted range is reduced by integral_period ns (typically only a few
> nanoseconds), which is negligible in practice.
> > > >
> > > > Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output
> > > > support")
> > > > Signed-off-by: Wei Fang <wei.fang@nxp.com>
> > >
> > > If so, then I think NETC_TMR_DEFAULT_FIPER can simply be used in
> > > place of max_period.
> >
> > Yes, I also considered this modification, but ultimately chose this
> > lazy approach. Since you brought it up, I will improve it in the next version.
> > Thanks. :)
> 
> Hopefully, not the lazy part. ;-)