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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024021557-remedial-mutilated-63c6@gregkh>
Date: Thu, 15 Feb 2024 18:49:04 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jürgen Groß <jgross@...e.com>
Cc: corbet@....net, workflows@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, security@...nel.org,
	linux@...mhuis.info, Kees Cook <keescook@...omium.org>,
	Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Lukas Bulwahn <lukas.bulwahn@...il.com>,
	Sasha Levin <sashal@...nel.org>, Lee Jones <lee@...nel.org>
Subject: Re: [PATCH v4] Documentation: Document the Linux Kernel CVE process

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

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