Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210913131113.390368911@linuxfoundation.org> <20210913131123.500712780@linuxfoundation.org>
 <CAK8P3a0z5jE=Z3Ps5bFTCFT7CHZR1JQ8VhdntDJAfsUxSPCcEw@mail.gmail.com> <874kak9moe.ffs@tglx>
In-Reply-To: <874kak9moe.ffs@tglx>
From:   Arnd Bergmann <arnd@kernel.org>
Date:   Fri, 17 Sep 2021 09:31:33 +0200
Message-ID: <CAK8P3a0mAOgo_7xVfHr2YfeKa8xQPH6GfafB96NPvFAnQF_LBg@mail.gmail.com>
Subject: Re: [PATCH 5.14 298/334] time: Handle negative seconds correctly in timespec64_to_ns()
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "# 3.4.x" <stable@vger.kernel.org>,
        Lukas Hannen <lukas.hannen@opensource.tttech-industrial.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Sep 17, 2021 at 12:32 AM Thomas Gleixner <tglx@linutronix.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