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

[Michal Koutný]

On Sat, Jul 27, 2024 at 09:34:18AM GMT, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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: signature.asc
Description: PGP signature