linux-kernel - Re: [PATCH 5.14 298/334] time: Handle negative seconds correctly 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]

Message-ID: <YURQ9o1rDeqmUkSL@kroah.com>
Date:   Fri, 17 Sep 2021 10:25:26 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "# 3.4.x" <stable@...r.kernel.org>,
        Lukas Hannen <lukas.hannen@...nsource.tttech-industrial.com>
Subject: Re: [PATCH 5.14 298/334] time: Handle negative seconds correctly in
 timespec64_to_ns()

On Fri, Sep 17, 2021 at 09:31:33AM +0200, Arnd Bergmann wrote:
> On Fri, Sep 17, 2021 at 12:32 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Wed, Sep 15 2021 at 21:00, Arnd Bergmann wrote:
> >
> > I have done the analysis. setitimer() does not have any problem with
> > that simply because it already checks at the call site that the seconds
> > value is > 0 and so do all the other user visible interfaces. See
> > get_itimerval() ...
> 
> Right, I now came to the same conclusion after taking a closer look,
> see my reply from yesterday.
> 
> > Granted  that the kernel internal interfaces do not have those checks,
> > but they already have other safety nets in place to prevent this and I
> > could not identify any callsite which has trouble with that change.
> >
> > If I failed to spot one then what the heck is the problem? It was broken
> > before that change already!
> 
> My bad for the unfortunate timing. When only saw the patch when Greg
> posted it during the stable review and wasn't completely sure about it
> at the time, so I was hoping that he could just hold off until you had a chance
> to reply either saying that you had already checked this case or that it
> was dangerous, but now it's already reverted.
> 
> I agree we should put back the fix into all stable kernels.

Ok, I'll queue it up again after this round goes out.

thanks for the additional review.

greg k-h