Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 6 Mar 2019 10:54:42 +0100
From:   Miroslav Lichvar <mlichvar@redhat.com>
To:     John Stultz <john.stultz@linaro.org>
Cc:     Xiongfeng Wang <wangxiongfeng2@huawei.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Stephen Boyd <sboyd@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
Message-ID: <20190306095442.GM21520@localhost>
References: <1551835710-53773-1-git-send-email-wangxiongfeng2@huawei.com>
 <CALAqxLXFGKDzxT-S9DDnjRRYvDB1Qq3T-tHYYGQXg3c47HtTbQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALAqxLXFGKDzxT-S9DDnjRRYvDB1Qq3T-tHYYGQXg3c47HtTbQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@linaro.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'

There was a patch submitted couple years ago that prevented overflows
in 32-bit time_t and ktime_t.

http://lkml.iu.edu/hypermail/linux/kernel/1510.0/04719.html

-- 
Miroslav Lichvar