* [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
@ 2019-03-06 1:28 Xiongfeng Wang
2019-03-06 1:42 ` John Stultz
0 siblings, 1 reply; 6+ messages in thread
From: Xiongfeng Wang @ 2019-03-06 1:28 UTC (permalink / raw)
To: john.stultz, tglx, sboyd; +Cc: linux-kernel, wangxiongfeng2
When I ran Syzkaller testsuite, I got the following call trace.
================================================================================
UBSAN: Undefined behaviour in kernel/time/ntp.c:457:16
signed integer overflow:
9223372036854775807 + 500 cannot be represented in type 'long int'
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.25-dirty #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
handle_overflow+0x193/0x1e2 lib/ubsan.c:190
second_overflow+0x403/0x540 kernel/time/ntp.c:457
accumulate_nsecs_to_secs kernel/time/timekeeping.c:2002 [inline]
logarithmic_accumulation kernel/time/timekeeping.c:2046 [inline]
timekeeping_advance+0x2bb/0xec0 kernel/time/timekeeping.c:2114
tick_do_update_jiffies64.part.2+0x1a0/0x350 kernel/time/tick-sched.c:97
tick_do_update_jiffies64 kernel/time/tick-sched.c:1229 [inline]
tick_nohz_update_jiffies kernel/time/tick-sched.c:499 [inline]
tick_nohz_irq_enter kernel/time/tick-sched.c:1232 [inline]
tick_irq_enter+0x1fd/0x240 kernel/time/tick-sched.c:1249
irq_enter+0xc4/0x100 kernel/softirq.c:353
entering_irq arch/x86/include/asm/apic.h:517 [inline]
entering_ack_irq arch/x86/include/asm/apic.h:523 [inline]
smp_apic_timer_interrupt+0x20/0x480 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:864
</IRQ>
RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
Code: 01 f0 0f 82 bc fd ff ff 48 c7 c7 c0 21 b1 83 e8 a1 0a 02 ff e9 ab fd ff ff 4c 89 e7 e8 77 b6 a5 fe e9 6a ff ff ff 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
RSP: 0018:ffff888106307d20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000007 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881062e4f1c
RBP: 0000000000000003 R08: ffffed107c5dc77b R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff848c78a0
R13: 0000000000000003 R14: 1ffff11020c60fae R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0x24/0x2b0 arch/x86/kernel/process.c:561
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x2ca/0x420 kernel/sched/idle.c:262
cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:368
start_secondary+0x421/0x570 arch/x86/kernel/smpboot.c:271
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
================================================================================
It is because time_maxerror is set as 0x7FFFFFFFFFFFFFFF by user. It
overflows when we add it with 'MAXFREQ / NSEC_PER_USEC' in
'second_overflow()'.
This patch add a limit check and saturate it when the user set
'time_maxerror'.
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
---
kernel/time/ntp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 36a2bef..38e1b65 100644
--- 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;
if (txc->modes & ADJ_ESTERROR)
time_esterror = txc->esterror;
--
1.7.12.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
2019-03-06 1:28 [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow() Xiongfeng Wang
@ 2019-03-06 1:42 ` John Stultz
2019-03-06 9:54 ` Miroslav Lichvar
0 siblings, 1 reply; 6+ messages in thread
From: John Stultz @ 2019-03-06 1:42 UTC (permalink / raw)
To: Xiongfeng Wang; +Cc: Thomas Gleixner, Stephen Boyd, lkml, Miroslav Lichvar
On Tue, Mar 5, 2019 at 5:29 PM Xiongfeng Wang <wangxiongfeng2@huawei.com> wrote:
>
> When I ran Syzkaller testsuite, I got the following call trace.
> ================================================================================
> UBSAN: Undefined behaviour in kernel/time/ntp.c:457:16
> signed integer overflow:
> 9223372036854775807 + 500 cannot be represented in type 'long int'
> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.25-dirty #2
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
> handle_overflow+0x193/0x1e2 lib/ubsan.c:190
> second_overflow+0x403/0x540 kernel/time/ntp.c:457
> accumulate_nsecs_to_secs kernel/time/timekeeping.c:2002 [inline]
> logarithmic_accumulation kernel/time/timekeeping.c:2046 [inline]
> timekeeping_advance+0x2bb/0xec0 kernel/time/timekeeping.c:2114
> tick_do_update_jiffies64.part.2+0x1a0/0x350 kernel/time/tick-sched.c:97
> tick_do_update_jiffies64 kernel/time/tick-sched.c:1229 [inline]
> tick_nohz_update_jiffies kernel/time/tick-sched.c:499 [inline]
> tick_nohz_irq_enter kernel/time/tick-sched.c:1232 [inline]
> tick_irq_enter+0x1fd/0x240 kernel/time/tick-sched.c:1249
> irq_enter+0xc4/0x100 kernel/softirq.c:353
> entering_irq arch/x86/include/asm/apic.h:517 [inline]
> entering_ack_irq arch/x86/include/asm/apic.h:523 [inline]
> smp_apic_timer_interrupt+0x20/0x480 arch/x86/kernel/apic/apic.c:1052
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:864
> </IRQ>
> RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
> Code: 01 f0 0f 82 bc fd ff ff 48 c7 c7 c0 21 b1 83 e8 a1 0a 02 ff e9 ab fd ff ff 4c 89 e7 e8 77 b6 a5 fe e9 6a ff ff ff 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
> RSP: 0018:ffff888106307d20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
> RAX: 0000000000000007 RBX: dffffc0000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881062e4f1c
> RBP: 0000000000000003 R08: ffffed107c5dc77b R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff848c78a0
> R13: 0000000000000003 R14: 1ffff11020c60fae R15: 0000000000000000
> arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
> default_idle+0x24/0x2b0 arch/x86/kernel/process.c:561
> cpuidle_idle_call kernel/sched/idle.c:153 [inline]
> do_idle+0x2ca/0x420 kernel/sched/idle.c:262
> cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:368
> start_secondary+0x421/0x570 arch/x86/kernel/smpboot.c:271
> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
> ================================================================================
>
> It is because time_maxerror is set as 0x7FFFFFFFFFFFFFFF by user. It
> overflows when we add it with 'MAXFREQ / NSEC_PER_USEC' in
> 'second_overflow()'.
>
> This patch add a limit check and saturate it when the user set
> 'time_maxerror'.
>
> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> ---
> kernel/time/ntp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> index 36a2bef..38e1b65 100644
> --- 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.
thanks
-john
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
2019-03-06 1:42 ` John Stultz
@ 2019-03-06 9:54 ` Miroslav Lichvar
2019-03-06 12:29 ` Thomas Gleixner
0 siblings, 1 reply; 6+ messages in thread
From: Miroslav Lichvar @ 2019-03-06 9:54 UTC (permalink / raw)
To: John Stultz; +Cc: Xiongfeng Wang, Thomas Gleixner, Stephen Boyd, lkml
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
2019-03-06 9:54 ` Miroslav Lichvar
@ 2019-03-06 12:29 ` Thomas Gleixner
2019-03-06 13:37 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2019-03-06 12:29 UTC (permalink / raw)
To: Miroslav Lichvar
Cc: John Stultz, Xiongfeng Wang, Stephen Boyd, lkml, Arnd Bergmann
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@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'
So once Arnd is done with y2038, we'll ask him to look into y2262 :)
Seriously, yes we should do clamping there.
Thanks,
tglx
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
2019-03-06 12:29 ` Thomas Gleixner
@ 2019-03-06 13:37 ` Arnd Bergmann
2019-03-07 5:10 ` Richard Cochran
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2019-03-06 13:37 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Miroslav Lichvar, John Stultz, Xiongfeng Wang, Stephen Boyd, lkml
On Wed, Mar 6, 2019 at 1:29 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 6 Mar 2019, Miroslav Lichvar wrote:
> > On Tue, Mar 05, 2019 at 05:42:25PM -0800, John Stultz wrote:
> So once Arnd is done with y2038, we'll ask him to look into y2262 :)
There is also y2070 (many RTCs), y2100 (some other RTCs, especially
those that assume it's a leap year), and y2106.
Arnd
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
2019-03-06 13:37 ` Arnd Bergmann
@ 2019-03-07 5:10 ` Richard Cochran
0 siblings, 0 replies; 6+ messages in thread
From: Richard Cochran @ 2019-03-07 5:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Thomas Gleixner, Miroslav Lichvar, John Stultz, Xiongfeng Wang,
Stephen Boyd, lkml
On Wed, Mar 06, 2019 at 02:37:21PM +0100, Arnd Bergmann wrote:
>
> There is also y2070 (many RTCs), y2100 (some other RTCs, especially
> those that assume it's a leap year), and y2106.
That's okay, Arnd. When the time comes you can come out of retirement
and cash in, doing Y2.07, Y2.1, and Y2.106K consulting ;^}
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-07 5:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-06 1:28 [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow() Xiongfeng Wang
2019-03-06 1:42 ` John Stultz
2019-03-06 9:54 ` Miroslav Lichvar
2019-03-06 12:29 ` Thomas Gleixner
2019-03-06 13:37 ` Arnd Bergmann
2019-03-07 5:10 ` Richard Cochran
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox