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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Jul 26, 2024 at 07:12:36AM -0700, Kees Cook wrote:
> 
> 
> On July 26, 2024 2:54:25 AM PDT, Greg Kroah-Hartman <gregkh@linuxfoundation.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@linuxfoundation.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.

We assigned a CVE to 9c573cd313433 as it was implied by many that this
was "fixing a weakness" in the security feature in 39218ff4c625d.  If
this is not the case, then we can revoke this CVE.

> 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.)

"improving an old one so it actually works" is fixing a vulnerability
(i.e. something that says it works but it wasn't), so those should be
getting a CVE if I am reading the requirements properly.

I too would love to assign CVEs to "a new mitigation feature was added
that you should be using", but I don't think that would fly :(

thanks,

greg k-h