lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1902271651330.26197@nanos.tec.linutronix.de>
Date:   Wed, 27 Feb 2019 16:52:47 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Yao HongBo <yaohongbo@...wei.com>
cc:     Deepa Dinamani <deepa.kernel@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linuxarm@...wei.com
Subject: Re: [PATCH] time64: Avoid undefined behaviour in timespec64_add()

On Mon, 25 Feb 2019, Yao HongBo wrote:
> On 2/25/2019 12:53 PM, Deepa Dinamani wrote:
> > On Sun, Feb 24, 2019 at 7:13 PM Hongbo Yao <yaohongbo@...wei.com> wrote:
> >> I ran into this:

> >>         UBSAN: Undefined behaviour in ./include/linux/time64.h:70:2
> >>         signed integer overflow:
> >>         1551059291 + 9223372036854775807 cannot be represented in type 'long
> >>         long int'
> >>         CPU: 5 PID: 20064 Comm: syz-executor.2 Not tainted 4.19.24 #4
> >>         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
> >>          timespec64_add include/linux/time64.h:70 [inline]
> >>          timekeeping_inject_offset+0x3ed/0x4e0 kernel/time/timekeeping.c:1301
> >>          do_adjtimex+0x1e5/0x6c0 kernel/time/timekeeping.c:2360
> >>          __do_sys_clock_adjtime+0x122/0x200 kernel/time/posix-timers.c:1086
> 
> > You seem to be adding INT64_MAX here. Maybe the right thing to do is
> > to add a check at the syscall interface rather than here.
> 
> Thanks for this suggestion. Looks like that is a better way.
> I will try it.

Yes, the input to sys_clock_adjtime() needs to be sanity checked.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ