linux-kernel - Re: CVE-2024-35918: randomize_kstack: Improve entropy diffusion

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: <D4CED3E9-5E5F-4E94-AB59-3EA617213DA1@kernel.org>
Date: Fri, 26 Jul 2024 07:12:36 -0700
From: Kees Cook <kees@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Michal Koutný <mkoutny@...e.com>
CC: cve@...nel.org, linux-kernel@...r.kernel.org,
 linux-cve-announce@...r.kernel.org, Kees Cook <keescook@...omium.org>
Subject: Re: CVE-2024-35918: randomize_kstack: Improve entropy diffusion



On July 26, 2024 2:54:25 AM PDT, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>On Fri, Jul 26, 2024 at 11:45:59AM +0200, Michal Koutný wrote:
>> Hello.
>> 
>> On Sun, May 19, 2024 at 12:11:12PM GMT, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>> > Description
>> > ===========
>> > 
>> > In the Linux kernel, the following vulnerability has been resolved:
>> > 
>> > randomize_kstack: Improve entropy diffusion
>> > 
>> > The kstack_offset variable was really only ever using the low bits for
>> > kernel stack offset entropy. Add a ror32() to increase bit diffusion.
>> > 
>> > The Linux kernel CVE team has assigned CVE-2024-35918 to this issue.
>> > 
>> > 
>> > Affected and fixed versions
>> > ===========================
>> > 
>> > 	Issue introduced in 5.13 with commit 39218ff4c625 and fixed in 5.15.155 with commit dfb2ce952143
>> > 	Issue introduced in 5.13 with commit 39218ff4c625 and fixed in 6.1.86 with commit e80b4980af26
>> > 	Issue introduced in 5.13 with commit 39218ff4c625 and fixed in 6.6.27 with commit 300a2b9c2b28
>> > 	Issue introduced in 5.13 with commit 39218ff4c625 and fixed in 6.8.6 with commit 6be74b1e21f8
>> > 	Issue introduced in 5.13 with commit 39218ff4c625 and fixed in 6.9 with commit 9c573cd31343
>> 
>> The commit
>> 9c573cd313433 ("randomize_kstack: Improve entropy diffusion") v6.9-rc4~35^2
>> adds ~2 bits of entropy to stack offsets (+the diffusion, x86_64)
>> 
>> The commit
>> 39218ff4c625d ("stack: Optionally randomize kernel stack offset each syscall") v5.13-rc1~184^2~3
>> adds ~8 bit of entropy to stack offsets (there was none before, x86_64)
>> 
>> Why the former commit has a CVE while the latter doesn't? (2 < 8)
>> 
>> I'd expect both to be treated equally or even inversely.
>
>If you wish for a CVE to be assigned to 39218ff4c625d, we will be glad
>to do so, but it was not on our "old list" of GSD entries to backfill in
>CVE entries for, which is why it was not assigned one.

I don't think either need a CVE. 39218ff4c625d added a new security flaw mitigation. 9c573cd313433 improved it. The original did what it said it did, so a CVE wouldn't seem to traditionally apply.

If adding a new mitigation feature (or improving an old one) means we need to issue CVEs against the earlier kernels, this would be a whole new class of CVE. (Though I would certainly support it: "your kernel is vulnerable because you're not using a new mitigation" is a message I've been trying to communicate forever.)

-Kees

-- 
Kees Cook