linux-kernel - Re: [PATCH RT 1/6] signal: Prevent double-free of user struct

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] [day] [month] [year] [list]

Date:   Thu, 13 Aug 2020 15:28:35 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>
Cc:     linux-kernel@...r.kernel.org,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Carsten Emde <C.Emde@...dl.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        John Kacur <jkacur@...hat.com>, Daniel Wagner <wagi@...om.org>,
        Tom Zanussi <zanussi@...nel.org>,
        "Srivatsa S. Bhat" <srivatsa@...il.mit.edu>,
        Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: [PATCH RT 1/6] signal: Prevent double-free of user struct

On Thu, 13 Aug 2020 10:25:45 +0200
Rasmus Villemoes <rasmus.villemoes@...vas.dk> wrote:

> On 13/08/2020 03.45, Steven Rostedt wrote:
> > 5.4.54-rt33-rc1 stable review patch.
> > If anyone has any objections, please let me know.
> >  
> 
> No objections, quite the contrary. I think this should also be applied
> to 4.19-rt:

Yep. We have a rule that no earlier supported stable release should
have a fix that a more recent stable release does not have. So this
needs to be accepted in 5.4-rt before 4.19-rt can have it. And those
maintainers have been waiting patiently for me to push this ;-)

> Three requests (in order of importance):
> 
> * pull this into 4.19-rt
> * add a note about the sigwaittest reproducer to the commit log

We don't usually add comments to the commit log for backported patches.

> * do publish the rt-rcs in some git repository; that makes it a lot
> easier to cherry-pick and test patches

This has been talked about before. Perhaps you should bring up posting
stable RT RC releases into git repositories at the RT microconference
at Plumbers ;-) Especially since the last time I asked about it, people
said it wasn't necessary.

https://linuxplumbersconf.org/event/7/page/80-accepted-microconferences#rt-cr

-- Steve