Re: UBSAN: Undefined behaviour in kernel/time/time.c:757:2

[John Stultz]

On Wed, Jan 27, 2016 at 7:14 AM, Toralf FÃrster <toralf.foerster@xxxxxx> 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