On Thu, Feb 15, 2024 at 04:03:02PM +0100, Jürgen Groß wrote: > On 15.02.24 13:10, 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. > > > > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > > Reviewed-by: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> > > Reviewed-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> > > Reviewed-by: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > Signed-off-by: Lee Jones <lee@xxxxxxxxxx> > > --- > > v4: Add MAINTAINER entry > > Lots of tiny wording changes based on many reviews > > Collected some Reviewed-by: tags > > Fixed documenation build by properly referencing the security > > process documentation file. > > v3: fix up wording in security-bugs.rst based on the changes to the cve > > assignment process from v1, thanks to a private reviewer for > > pointing that out. > > v2: Grammer fixes based on review from Randy > > Updated paragraph about how CVE identifiers will be assigned > > (automatically when added to stable trees, or ask us for one > > directly before that happens if so desired) > > > > Documentation/process/cve.rst | 120 ++++++++++++++++++++++++ > > Documentation/process/index.rst | 1 + > > Documentation/process/security-bugs.rst | 5 +- > > MAINTAINERS | 5 + > > 4 files changed, 128 insertions(+), 3 deletions(-) > > create mode 100644 Documentation/process/cve.rst > > > > diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst > > new file mode 100644 > > index 000000000000..6b244d938694 > > --- /dev/null > > +++ b/Documentation/process/cve.rst > > @@ -0,0 +1,120 @@ > > ... > > > +Invalid CVEs > > +------------ > > + > > +If a security issue is found in a Linux kernel that is only supported by > > +a Linux distribution due to the changes that have been made by that > > +distribution, or due to the distribution supporting a kernel version > > +that is no longer one of the kernel.org supported releases, then a CVE > > +can not be assigned by the Linux kernel CVE team, and must be asked for > > +from that Linux distribution itself. > > + > > +Any CVE that is assigned against the Linux kernel for an actively > > +supported kernel version, by any group other than the kernel assignment > > +CVE team should not be treated as a valid CVE. Please notify the > > +kernel CVE assignment team at <cve@xxxxxxxxxx> so that they can work to > > +invalidate such entries through the CNA remediation process. > > Today we (the Xen security team) are allocating CVEs for Xen-related > kernel security bugs. > > Does this mean we should do that via cve@xxxxxxxxxx in future, or are > you happy us continuing our process as today? If the latter, I think > this should be noted somehow in this document in order to avoid complaints > regarding CVEs allocated by us. > > > Juergen (on behalf of the Xen security team) That's a good question, and from what I can tell for the "rules" here, yes, we need to coordinate somehow for anything that is Linux kernel-only. Just email us and ask us for an id and our tools can take it from there for the submission and other stuff, so hopefully this will make things easier. For stuff that crosses both sides (Xen and Linux), you are free to create your own CVE and then use that identifier in the kernel patch like you have in the past as I would consider Xen being the "primary" CNA, don't you? Is that ok? We want to make this as easy as possible, so I don't want to get in the way of your existing process if at all possible. thanks, greg k-h
