linux-kernel - Re: [RFC PATCH] ntp: Avoid undefined behaviour in second

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]

Date:   Wed, 6 Mar 2019 13:29:48 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Miroslav Lichvar <mlichvar@...hat.com>
cc:     John Stultz <john.stultz@...aro.org>,
        Xiongfeng Wang <wangxiongfeng2@...wei.com>,
        Stephen Boyd <sboyd@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [RFC PATCH] ntp: Avoid undefined behaviour in
 second_overflow()

On Wed, 6 Mar 2019, Miroslav Lichvar wrote:
> On Tue, Mar 05, 2019 at 05:42:25PM -0800, John Stultz wrote:
> > > --- a/kernel/time/ntp.c
> > > +++ b/kernel/time/ntp.c
> > > @@ -677,6 +677,8 @@ static inline void process_adjtimex_modes(const struct timex *txc, s32 *time_tai
> > >
> > >         if (txc->modes & ADJ_MAXERROR)
> > >                 time_maxerror = txc->maxerror;
> > > +       if (time_maxerror > NTP_PHASE_LIMIT)
> > > +               time_maxerror = NTP_PHASE_LIMIT;
> > 
> > This looks sane to me.
> > Acked-by: John Stultz <john.stultz@...aro.org>
> > 
> > Though it makes me wonder a bit more about the sanity checking on the
> > other parameters passed via adjtimex(), tick_usec for instance looks
> > like it could be similarly problematic.
> 
> The tick length is checked earlier in timekeeping_validate_timex(), so
> that should be ok.
> 
> What I'd like to see clamped is the system time itself. ktime_t
> overflows on Apr 11 2262. clock_settime() and adjtimex(ADJ_SETOFFSET)
> can set the time close to the overflow and let everything break.
> 
> Boot a VM and try this:
> 
> # date -s 'Apr 11 23:47:15 UTC 2262'

So once Arnd is done with y2038, we'll ask him to look into y2262 :)

Seriously, yes we should do clamping there.

Thanks,

	tglx