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]
Message-ID: <a399670d-1fd8-c948-b4db-b2396290c22a@gmx.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ