linux-kernel - RE: [PATCH] time: Avoid undefined behaviour in timespec64_to

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, 15 Sep 2020 12:20:45 +0000
From:   "Zengtao (B)" <prime.zeng@...ilicon.com>
To:     Arnd Bergmann <arnd@...db.de>
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

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@...db.de]
> Sent: Tuesday, September 01, 2020 8:47 PM
> To: Zengtao (B)
> Cc: Thomas Gleixner; Vincenzo Frascino; 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?
> 

I think we need to do the backport, but not sure about the start point
Thanks for your review. 

> Cc <stable@...r.kernel.org> # v3.17+
> 
> > Signed-off-by: Zeng Tao <prime.zeng@...ilicon.com>
> 
> Reviewed-by: Arnd Bergmann <arnd@...db.de>