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

[Kees Cook]

On July 26, 2024 2:54:25 AM PDT, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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