linux-kernel - Re: [PATCH] usercopy: Do not fail on memory from former init sections

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:   Sat, 8 Jan 2022 01:22:59 +0100
From:   Helge Deller <deller@....de>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Linux Kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        linux-parisc@...r.kernel.org
Subject: Re: [PATCH] usercopy: Do not fail on memory from former init sections

Hi Andrew,

On 1/8/22 00:51, Andrew Morton wrote:
> On Fri, 7 Jan 2022 01:19:24 +0100 Helge Deller <deller@....de> wrote:
>
>> On some platforms the memory area between the _stext and the _etext
>> symbols includes the init sections (parisc and csky). If the init
>> sections are freed after bootup, the kernel may reuse this memory.
>>
>> In one test the usercopy checks if the given address is inside the .text
>> section (from _stext to _etext), and it wrongly fails on the mentioned
>> platforms if the memory is from the former init section.
>>
>> Fix this failure by first checking against the init sections before
>> checking against the _stext/_etext section.
>>
>> Signed-off-by: Helge Deller <deller@....de>
>> Fixes: 98400ad75e95 ("parisc: Fix backtrace to always include init funtion names")

You asked:
> This sounds like it might have very serious runtime effects?

Yes, the patch fixes very negative effects in the sense that the kernel fails to boot
on parisc if the following patch is included (and if userchecks are enabled):
279917e27edc - parisc: Fix backtrace to always include init funtion names

That patch (279917e27edc) was once in v5.16, but because of the failure
I *reverted* it again with:
98400ad75e95 - Revert "parisc: Fix backtrace to always include init funtion names"

Both patches were originally tagged for stable.
So, all current trees are fine as they are right now as they are.

> And 98400ad75e95 has cc:stable so we'll want cc:stable on this patch
> also, yes?

We could push it to stable if we think it's worth it.
But I'm fine if we simply start fresh with kernel 5.17.
So: no.

> So is this a must-have for 5.16?

No. Current trees are fine.

> And I really wouldn't want to jam a patch into mm/usercopy.c at this
> point in the life of 5.16 anyway.

Right.
I sent the patch for review and for v5.17 (it didn't had a stable tag).

It would be nice if you could queue it up for v5.17.

Helge