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

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

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

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.

Thanks,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Greg Kroah-Hartman]

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.

thanks,

greg k-h

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

[Kees Cook]

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.

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

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

[Greg Kroah-Hartman]

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

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

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On Sat, Jul 27, 2024 at 09:34:18AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 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 9c573cd313433 (fixup) is fixing a weakness of too few bits in stack offset
randomization, then 39218ff4c625d (feature) is fixing such a weakness too.

Or equivalently, if 39218ff4c625d is not fixing a weakness of too few
bits in stack offset randomization, then 9c573cd313433 is not fixing it
neither.

By this reasoning I'd be for stripping this CVE. Both patches would thus
be equal. (As suggested by Kees.)
(Also to avoid going into the rabbit hole of how many bits of
randomization are enough.)

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

This could apply if the implementation somehow mistakenly
short-circuited the offset to always 0 (or in the case of some other
features with a strict threshold) but I don't think it works here due to
the fuzzy nature of randomization.

> 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 :(

It would be suboptimal use of CVEs (not to mention that features are not
trivial to backport).


Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Kees Cook]

On Mon, Jul 29, 2024 at 04:35:52PM +0200, Michal Koutný wrote:
> On Sat, Jul 27, 2024 at 09:34:18AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 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 9c573cd313433 (fixup) is fixing a weakness of too few bits in stack offset
> randomization, then 39218ff4c625d (feature) is fixing such a weakness too.
> 
> Or equivalently, if 39218ff4c625d is not fixing a weakness of too few
> bits in stack offset randomization, then 9c573cd313433 is not fixing it
> neither.
> 
> By this reasoning I'd be for stripping this CVE. Both patches would thus
> be equal. (As suggested by Kees.)
> (Also to avoid going into the rabbit hole of how many bits of
> randomization are enough.)

Yeah, I think it's best to have neither be a CVE.

-- 
Kees Cook

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

[Greg Kroah-Hartman]

On Mon, Jul 29, 2024 at 05:15:52PM -0700, Kees Cook wrote:
> On Mon, Jul 29, 2024 at 04:35:52PM +0200, Michal Koutný wrote:
> > On Sat, Jul 27, 2024 at 09:34:18AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > 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 9c573cd313433 (fixup) is fixing a weakness of too few bits in stack offset
> > randomization, then 39218ff4c625d (feature) is fixing such a weakness too.
> > 
> > Or equivalently, if 39218ff4c625d is not fixing a weakness of too few
> > bits in stack offset randomization, then 9c573cd313433 is not fixing it
> > neither.
> > 
> > By this reasoning I'd be for stripping this CVE. Both patches would thus
> > be equal. (As suggested by Kees.)
> > (Also to avoid going into the rabbit hole of how many bits of
> > randomization are enough.)
> 
> Yeah, I think it's best to have neither be a CVE.

The CVE has now been rejected, thanks for the review!

greg k-h

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

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

On Tue, Jul 30, 2024 at 06:56:42AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Mon, Jul 29, 2024 at 05:15:52PM -0700, Kees Cook wrote:
> ...
> > Yeah, I think it's best to have neither be a CVE.
> 
> The CVE has now been rejected, thanks for the review!

Thank you both!

Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]