linux-kernel - Re: Regression in posix-cpu-timers.c (was Re: Linux 5.14.4)

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: <20210915183152.GA22415@lothringen>
Date:   Wed, 15 Sep 2021 20:31:52 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     "Alan J. Wylie" <alan@...ie.me.uk>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: Regression in posix-cpu-timers.c (was Re: Linux 5.14.4)

On Wed, Sep 15, 2021 at 06:45:33PM +0100, Alan J. Wylie wrote:
> 564005805aadec9cb7e5dc4e14071b8f87cd6b58 is the first bad commit
> commit 564005805aadec9cb7e5dc4e14071b8f87cd6b58
> Author: Frederic Weisbecker <frederic@...nel.org>
> Date:   Mon Jul 26 14:55:10 2021 +0200
> 
>     posix-cpu-timers: Force next expiration recalc after itimer reset
>     
>     [ Upstream commit 406dd42bd1ba0c01babf9cde169bb319e52f6147 ]
>     
>     When an itimer deactivates a previously armed expiration, it simply doesn't
>     do anything. As a result the process wide cputime counter keeps running and
>     the tick dependency stays set until it reaches the old ghost expiration
>     value.
>     
>     This can be reproduced with the following snippet:
>     
>             void trigger_process_counter(void)
>             {
>                     struct itimerval n = {};
>     
>                     n.it_value.tv_sec = 100;
>                     setitimer(ITIMER_VIRTUAL, &n, NULL);
>                     n.it_value.tv_sec = 0;
>                     setitimer(ITIMER_VIRTUAL, &n, NULL);
>             }
>     
>     Fix this with resetting the relevant base expiration. This is similar to
>     disarming a timer.
>     
>     Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
>     Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>     Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>     Link: https://lore.kernel.org/r/20210726125513.271824-4-frederic@kernel.org
>     Signed-off-by: Sasha Levin <sashal@...nel.org>
>

Right, this should fix the issue: https://lore.kernel.org/lkml/20210913145332.232023-1-frederic@kernel.org/

Thanks!