[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALAqxLVUNdsfrJnRU-YmBuYW-itUeUAO3mG5RsjrwUaPqe2x1Q@mail.gmail.com>
Date: Wed, 27 Jan 2016 12:08:38 -0800
From: John Stultz <john.stultz@...aro.org>
To: Toralf Förster <toralf.foerster@....de>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: UBSAN: Undefined behaviour in kernel/time/time.c:757:2
On Wed, Jan 27, 2016 at 7:14 AM, Toralf Förster <toralf.foerster@....de> wrote:
>
> Got this at a 32 bit Gentoo Linux in a KVM fuzz tested with trinity :
>
> Jan 27 15:43:30 n22kvm-clone kernel: ================================================================================
> Jan 27 15:43:30 n22kvm-clone kernel: UBSAN: Undefined behaviour in kernel/time/time.c:757:2
> Jan 27 15:43:30 n22kvm-clone kernel: signed integer overflow:
> Jan 27 15:43:30 n22kvm-clone kernel: 2614 + 2147483647 cannot be represented in type 'long int'
> Jan 27 15:43:30 n22kvm-clone kernel: CPU: 1 PID: 32724 Comm: trinity-c0 Not tainted 4.5.0-rc1 #1
> Jan 27 15:43:30 n22kvm-clone kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> Jan 27 15:43:30 n22kvm-clone kernel: 7fffffff 00000000 f04e7da4 d2bcd78b 00000007 f04e7dd4 f04e7db4 d2c31bbe
> Jan 27 15:43:30 n22kvm-clone kernel: f04e7db4 d3456528 f04e7e38 d2c31f0b d3308e5c f04e7dd8 0000002b f04e7e00
> Jan 27 15:43:30 n22kvm-clone kernel: d3456528 0000002b 00000286 34313632 00000000 00000086 00000086 00000014
> Jan 27 15:43:30 n22kvm-clone kernel: Call Trace:
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2bcd78b>] dump_stack+0x42/0x67
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2c31bbe>] ubsan_epilogue+0xe/0x40
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2c31f0b>] handle_overflow+0xbb/0xf0
> Jan 27 15:43:30 n22kvm-clone kernel: [<d26816a0>] ? kvm_clock_read+0x20/0x20
> Jan 27 15:43:30 n22kvm-clone kernel: [<d26816b7>] ? kvm_clock_get_cycles+0x17/0x20
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2c31f52>] __ubsan_handle_add_overflow+0x12/0x20
> Jan 27 15:43:30 n22kvm-clone kernel: [<d27636f5>] timespec_add_safe+0x1a5/0x1c0
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2951cb8>] poll_select_set_timeout+0x68/0xf0
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2f03ae9>] __sys_recvmmsg+0x29/0x3d0
> Jan 27 15:43:30 n22kvm-clone kernel: [<d27d8676>] ? __audit_syscall_entry+0x106/0x2a0
> Jan 27 15:43:30 n22kvm-clone kernel: [<d26017b2>] ? do_audit_syscall_entry.isra.11+0x72/0xf0
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2be902a>] ? _copy_from_user+0x4a/0x80
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2f04b40>] SyS_recvmmsg+0x60/0xd0
> Jan 27 15:43:30 n22kvm-clone kernel: [<d260333f>] do_fast_syscall_32+0x14f/0x940
> Jan 27 15:43:30 n22kvm-clone kernel: [<d2f04ae0>] ? SYSC_socketcall+0xc50/0xc50
> Jan 27 15:43:30 n22kvm-clone kernel: [<d31882a1>] sysenter_past_esp+0x42/0x69
> Jan 27 15:43:30 n22kvm-clone kernel: ================================================================================--
> Toralf, pgp: C4EACDDE 0076E94E
So that looks like its in timespec_add_safe():
Where we call:
set_normalized_timespec(&res, lhs.tv_sec + rhs.tv_sec,
lhs.tv_nsec + rhs.tv_nsec);
But right after it we handle the overflow case:
if (res.tv_sec < lhs.tv_sec || res.tv_sec < rhs.tv_sec)
res.tv_sec = TIME_T_MAX;
So I'm not sure I see the issue at the moment. Curious if you had more
specific thoughts?
thanks
-john
Powered by blists - more mailing lists