Messages in this thread Patch in this message | | | Date | Wed, 14 Feb 2024 09:37:31 +0100 | Subject | Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process | From | Vegard Nossum <> |
| |
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@k.org 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@kernel.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
| |