On 15.02.24 18:49, Greg Kroah-Hartman wrote:
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.
Okay, thanks, noted.
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?
We didn't have this case so far, and I think we'd just have one CVE for Xen
and one for Linux. Nevertheless good to know should this case ever come up.
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.
Yes, thanks, this is okay. Just wanted to have it spelled out. :-)
Juergen
