linux-kernel - Re: [PATCH] ntp: safeguard against time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <zhb5dy6ysbdghj3vhnj2s3gd7fhqg3v7xmhonkgfxp33qtc6bw@pqyhntprkwjr>
Date: Tue, 7 May 2024 22:03:18 +0000
From: Justin Stitt <justinstitt@...gle.com>
To: John Stultz <jstultz@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Stephen Boyd <sboyd@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Bill Wendling <morbo@...gle.com>, linux-kernel@...r.kernel.org, 
	llvm@...ts.linux.dev
Subject: Re: [PATCH] ntp: safeguard against time_constant overflow case

Hi,

On Mon, May 06, 2024 at 11:02:17PM -0700, John Stultz wrote:
> On Mon, May 6, 2024 at 3:01 PM Justin Stitt <justinstitt@...gle.com> wrote:
> >
> > Nonetheless, let's slightly rework the logic surrounding time_constant
> > and how it is incremented such that we avoid unintentional wrap-around
> > (even though it is extremely unlikely to be hit in non-fuzzing scenarios).
> >
> > [1]: https://github.com/llvm/llvm-project/pull/82432
> >
> > Signed-off-by: Justin Stitt <justinstitt@...gle.com>
> > ---
> >  kernel/time/ntp.c | 11 +++++++----
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> > index 406dccb79c2b..a9f039601968 100644
> > --- a/kernel/time/ntp.c
> > +++ b/kernel/time/ntp.c
> > @@ -65,6 +65,9 @@ static s64                    time_offset;
> >  /* pll time constant:                                                  */
> >  static long                    time_constant = 2;
> >
> > +/* pll time constant increment:                                                */
> > +static long                    time_constant_inc = 4;
> > +
> 
> I'd probably use a `#define TIME_CONSTANT_INC 4` for this.
> 
> >  /* maximum error (usecs):                                              */
> >  static long                    time_maxerror = NTP_PHASE_LIMIT;
> >
> > @@ -734,10 +737,10 @@ static inline void process_adjtimex_modes(const struct __kernel_timex *txc,
> >
> >         if (txc->modes & ADJ_TIMECONST) {
> >                 time_constant = txc->constant;
> > -               if (!(time_status & STA_NANO))
> > -                       time_constant += 4;
> > -               time_constant = min(time_constant, (long)MAXTC);
> > -               time_constant = max(time_constant, 0l);
> > +               if (!(time_status & STA_NANO) &&
> > +                   unlikely(LONG_MAX - time_constant_inc >= time_constant))
> > +                       time_constant += time_constant_inc;
> > +               time_constant = clamp_t(long, time_constant, 0, MAXTC);
> >         }
> 
> Overall, this looks fine. Though the time_status conditional is now a
> little unwieldy.
> 
> I wonder if some sort of a helper like:
>       time_constant = safe_add(time_constant, TIME_CONSTANT_INC, LONG_MAX);
> 
> Might make this a little easier to read?

How about something like this:

	if (txc->modes & ADJ_TIMECONST) {
		if (!(time_status & STA_NANO))
			time_constant = clamp_t(long, txc->constant,
						-TIME_CONSTANT_INC,
						MAXTC - TIME_CONSTANT_INC) +
						TIME_CONSTANT_INC;
		else
			time_constant = clamp_t(long, txc->constant, 0, MAXTC);
	}

We can remove the initial assignment and use some fancy clamps.

> 
> thanks
> -john

Thanks
Justin