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] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 1 Sep 2020 14:46:52 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Zeng Tao <prime.zeng@...ilicon.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] time: Avoid undefined behaviour in timespec64_to_ns

On Tue, Sep 1, 2020 at 11:32 AM Zeng Tao <prime.zeng@...ilicon.com> wrote:
>
> Since commit bd40a175769d ("y2038: itimer: change implementation to timespec64")
> we have break the time clamping which handles the potential overflow.

Indeed, good catch!

And I broke it despite the comment telling me about the problem.

> In this patch, we fix it in the timespec64_to_ns because there is
> possiblity to cause the same undefined behaviour on overflow whenever
> the function is called.

I checked the most important callers of this function, and I agree
that truncating at the maximum would be sensible in most cases
here.

In timekeeping_init(), there is already a check for
timespec64_valid_settod() that limits it even further, but that
wouldn't make sense for most callers.

> Fixes: bd40a175769d ("y2038: itimer: change implementation to timespec64")

This one caused the regression, but if we add the check here, it
may be best to also add it in prior kernels that may have the same
bug in other callers of the same function. Maybe backport all the
way to stable kernels that first added timespec64?

Cc <stable@...r.kernel.org> # v3.17+

> Signed-off-by: Zeng Tao <prime.zeng@...ilicon.com>

Reviewed-by: Arnd Bergmann <arnd@...db.de>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ