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]

Date:   Fri, 17 Sep 2021 09:31:33 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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 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.

        Arnd