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: <20220407215802.GB186606@roeck-us.net>
Date:   Thu, 7 Apr 2022 14:58:02 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>, jstultz@...gle.com,
        Stephen Boyd <sboyd@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [RFC][PATCH] timers: Add del_time_free() to be called before
 freeing timers

Hi Steven,

On Thu, Apr 07, 2022 at 04:17:45PM -0400, Steven Rostedt wrote:
> [
>   This is an RFC patch. As we hit a few bugs were del_timer() is called
>   instead of del_timer_sync() before the timer is freed, and there could
>   be bugs where even del_timer_sync() is used, but the timer gets rearmed,
>   I decided to introduce a "del_timer_free()" function that can be used
>   instead. This will at least educate developers on what to call before they
>   free a structure that holds a timer.
> 
>   In this RFC, I modified hci_qca.c as a use case, even though that change
>   needs some work, because the workqueue could still rearm it (I'm looking
>   to see if I can trigger the warning).
> 
>   If this approach is acceptable, then I will remove the hci_qca.c portion
>   from this patch, and create a series of patches to use the
>   del_timer_free() in all the locations in the kernel that remove the timer
>   before freeing.
> ]
> 
> From: "Steven Rostedt (Google)" <rostedt@...dmis.org>
> 
> We are hitting a common bug were a timer is being triggered after it is
> freed. This causes a corruption in the timer link list and crashes the
> kernel. Unfortunately it is not easy to know what timer it was that was
> freed. Looking at the code, it appears that there are several cases that
> del_timer() is used when del_timer_sync() should have been.
> 
> Add a del_timer_free() that not only does a del_timer_sync() but will mark

This limits the use case to situations where del_timer_sync() can actually
be called. There is, however, code where this is not possible.
Specifically, it doesn't work if the code triggered with the timer uses a
lock, and del_timer() is also called under that same lock. An example for
that is the code in sound/synth/emux/emux.c. How do you suggest to handle
that situation ?

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ