Re: [PATCH v4] Documentation: Document the Linux Kernel CVE process

["Jürgen Groß" <jgross@suse.com>]

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@chromium.org>
>>> Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
>>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>>> Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>> Signed-off-by: Lee Jones <lee@kernel.org>
>>> ---
>>> 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@kernel.org> 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@kernel.org 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