linux-kernel - Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

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]

Date: Thu, 15 Feb 2024 09:17:59 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, corbet@....net,
 workflows@...r.kernel.org
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 security@...nel.org, Kees Cook <keescook@...omium.org>,
 Sasha Levin <sashal@...nel.org>, Lee Jones <lee@...nel.org>
Subject: Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

On 14.02.24 09:00, Greg Kroah-Hartman wrote:
> The Linux kernel project now has the ability to assign CVEs to fixed
> issues, so document the process and how individual developers can get a
> CVE if one is not automatically assigned for their fixes.
> [...]

This following is just nitpicking, hence feel free to ignore.

> +As always, it is best to take all released kernel changes, as they are
> +tested together in a unified whole by many community members, and not as
> +individual cherry-picked changes.  Also note that for many bugs, the
> +solution to the overall problem is not found in a single change, but by
> +the sum of many fixes on top of each other.  Ideally CVEs will be
> +assigned to all fixes for all issues, but sometimes we do not notice
> +fixes in released kernels, so do not assume that because a specific
> +change does not have a CVE assigned to it, that it is not relevant to
> +take.

There are a four "not" in the last pretty long sentence which makes it
kinda hard to parse. Avoiding that could look like this:

Ideally CVEs will be assigned to all fixes for all issues -- but
sometimes we will fail to notice fixes, therefore assume that some
changes without an assigned CVE might still be relevant to take.

Or like this:

Ideally CVEs will be assigned to all fixes for all issues, but sometimes
we will overlook fixes -- therefore assume that some changes that lack
an assigned CVE might still be relevant to take.

Not sure if that really makes it better, I guess you as a native speaker
are a better judge here.

Ciao, Thorsten (who also wondered what "to all fixes for all issues"
exactly means, but whatever)