[RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
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: __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 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 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90 RSP: 0018:888106307d20 EFLAGS: 0246 ORIG_RAX: ff13 RAX: 0007 RBX: dc00 RCX: RDX: RSI: 0001 RDI: 8881062e4f1c RBP: 0003 R08: ed107c5dc77b R09: R10: R11: R12: 848c78a0 R13: 0003 R14: 111020c60fae R15: 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 0x7FFF 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 --- 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
Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
On Tue, Mar 5, 2019 at 5:29 PM Xiongfeng Wang 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: > > __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 > > 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 0f 1f 00 66 2e 0f > 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90 > RSP: 0018:888106307d20 EFLAGS: 0246 ORIG_RAX: ff13 > RAX: 0007 RBX: dc00 RCX: > RDX: RSI: 0001 RDI: 8881062e4f1c > RBP: 0003 R08: ed107c5dc77b R09: > R10: R11: R12: 848c78a0 > R13: 0003 R14: 111020c60fae R15: > 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 0x7FFF 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 > --- > 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 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
Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
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 > > 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
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 > > > > 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
Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
On Wed, Mar 6, 2019 at 1:29 PM Thomas Gleixner 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
Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()
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
