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: <u7iq6sax7trmasfpqqe5val5qr7d4odjokww3cxpav7mibgipn@fpxugdvez66s>
Date: Mon, 29 Jul 2024 16:35:52 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Kees Cook <kees@...nel.org>, 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 Sat, Jul 27, 2024 at 09:34:18AM GMT, Greg Kroah-Hartman <gregkh@...uxfoundation.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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)