linux-kernel - Re: [PATCH 5.4 000/168] 5.4.25-stable review

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:   Tue, 10 Mar 2020 16:07:23 +0100
From:   Holger Hoffstätte <holger@...lied-asynchrony.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, linux@...ck-us.net, shuah@...nel.org,
        stable@...r.kernel.org, Paolo Valente <paolo.valente@...aro.org>
Subject: Re: [PATCH 5.4 000/168] 5.4.25-stable review

On 3/10/20 4:00 PM, Greg Kroah-Hartman wrote:
> On Tue, Mar 10, 2020 at 03:51:01PM +0100, Holger Hoffstätte wrote:
>> On 3/10/20 3:35 PM, Greg Kroah-Hartman wrote:
>>> On Tue, Mar 10, 2020 at 03:02:37PM +0100, Holger Hoffstätte wrote:
>>>> On 3/10/20 1:37 PM, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.4.25 release.
>>>>
>>>> This fails to compile due to broken patch 001/168:
>>>> "block, bfq: get a ref to a group when adding it to a service tree":
>>>>
>>>> ..
>>>> block/bfq-wf2q.c: In function 'bfq_get_entity':
>>>> ./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity'
>>>> ..
>>>>
>>>> The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put
>>>> in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise
>>>> the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
>>>> This horribly error-prone #ifdef mess was finally removed in upstream commit
>>>> 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.
>>>
>>> Ick, that's a mess.
>>>
>>> I'll go drop that patch now, odd that it passed my build tests...
>>
>> Uh, please no? It fixes a rather nasty UAF when cgroups are in use.
>> Please just add the other upstream commit as well, I confirmed it applies
>> cleanly and fixes the problem.
> 
> I didn't get that from your email at all, sorry.
> 
> So, what commits, and in what order, should be applied to 5.4.y at the
> moment to resolve this issue?

Just add upstream 4d8340d0d4d9 and it should work. Order shouldn't matter
(built for me either way) unless you want to follow upstream, in which case
it should come before "get a ref to a group..". Easy :)

-h