[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00057b93-b5fc-4536-b13d-cd3b6cead5b1@oracle.com>
Date: Wed, 14 Feb 2024 09:37:31 +0100
From: Vegard Nossum <vegard.nossum@...cle.com>
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/2024 09:00, Greg Kroah-Hartman wrote:
> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst
> new file mode 100644
> index 000000000000..6465e6a79c18
> --- /dev/null
> +++ b/Documentation/process/cve.rst
> @@ -0,0 +1,120 @@
> +CVEs
> +====
Document titles should have ==== above them as well, and then you would
need to shift all the other headings in this document (i.e. all the ---
should become ===).
Info here:
https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation
> +The Linux kernel developer team does have the ability to assign CVEs for
> +potential Linux kernel security issues. This assignment is independent
> +of the :doc:`normal Linux kernel security bug reporting
> +process<../process/security_bugs>`.
These documents are both under process/ so it should be enough to say:
:doc:`[...] <security-bugs>`
In fact, when building the docs with your patch applied, I see:
Documentation/process/cve.rst:15: WARNING: unknown document:
./process/security_bugs
Documentation/process/cve.rst:42: WARNING: unknown document:
./process/security_bugs
Note the hyphen vs. underscore (it should have a hyphen like my line above).
> +Process
> +-------
> +
> +As part of the normal stable release process, kernel changes that are
> +potentially security issues are identified by the developers responsible
> +for CVE number assignments and have CVE numbers automatically assigned
> +to them. These assignments are published on the linux-cve-announce
> +mailing list as announcements on a frequent basis.
> +
> +Note, due to the layer at which the Linux kernel is in a system, almost
> +any bug might be exploitable to compromise the security of the kernel,
> +but the possibility of exploitation is often not evident when the bug is
> +fixed. Because of this, the CVE assignment team is overly cautious and
What is the composition of the CVE assignment team, or is that secret?
Should this be a MAINTAINERS entry? (s@...rg is one.)
> +If the CVE assignment team misses a specific fix that any user feels
> +should have a CVE assigned to it, please email them at <cve@...nel.org>
> +and the team there will work with you on it. Note that no potential
> +security issues should be sent to this alias, it is ONLY for assignment
> +of CVEs for fixes that are already in released kernel trees. If you
> +feel you have found an unfixed security issue, please follow the
> +:doc:`normal Linux kernel security bug reporting
> +process<../process/security_bugs>`.
Same
> +Disputes of assigned CVEs
> +-------------------------
> +
> +The authority to dispute or modify an assigned CVE for a specific kernel
> +change lies solely with the maintainers of the relevant subsystem
> +affected. This principle ensures a high degree of accuracy and
> +accountability in vulnerability reporting. Only those individuals with
> +deep expertise and intimate knowledge of the subsystem can effectively
> +assess the validity and scope of a reported vulnerability and determine
> +its appropriate CVE designation. Any attempt to modify or dispute a CVE
> +outside of this designated authority could lead to confusion, inaccurate
> +reporting, and ultimately, compromised systems.
Just to clarify, I think "dispute" here is used in the
Mitre/CVE-technical meaning of the word, correct? I assume people will
still have the right to say "hey, this doesn't look like a real issue
[because of X/Y/Z]" on a mailing list.
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -99,9 +99,8 @@ CVE assignment
> The security team does not assign CVEs, nor do we require them for
> reports or fixes, as this can needlessly complicate the process and may
> delay the bug handling. If a reporter wishes to have a CVE identifier
> -assigned, they should find one by themselves, for example by contacting
> -MITRE directly. However under no circumstances will a patch inclusion
> -be delayed to wait for a CVE identifier to arrive.
> +assigned for a confirmed issue, they can contact the :doc:`kernel CVE
> +assignment team<../process/cve>` to obtain one.
Same here, this could be just <cve>.
Vegard
Powered by blists - more mailing lists