linux-kernel - Re: [PATCH v3] 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]

Date: Thu, 15 Feb 2024 19:20:09 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Michal Hocko <mhocko@...e.com>
Cc: corbet@....net, workflows@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, security@...nel.org,
	Kees Cook <keescook@...omium.org>, Sasha Levin <sashal@...nel.org>,
	Lee Jones <lee@...nel.org>
Subject: Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote:
> On Wed 14-02-24 09:00:30, Greg KH wrote:
> [...]
> > +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
> > +assign CVE numbers to any bugfix that they identify.  This
> > +explains the seemingly large number of CVEs that are issued by the Linux
> > +kernel team.
> 
> Does the process focus only on assigning CVE numbers to a given upstream
> commit(s) withou any specifics of the actual security threat covered by
> the said CVE?

Outside of the git commit text, no, we are not going to be adding
anything additional to the report, UNLESS someone wants to add
additional text to it, and then we will be glad to update a CVE entry
with the additional information.

Here's an example of what the CVE announcement is going to look like for
a "test" that we have been doing for our scripts
	https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u

Note, I am NOT saying this is a valid CVE-like commit, I only chose it
because it is a type of entry that our tools need to handle properly
(one where the fix was for a commit that was only in a stable tree, and
mainline never saw the problem.)  There are many different "styles" of
fixes that we need to handle when it comes to version information.

It will also be in JSON format on the cve.org site if you wish to parse
it automatically with tools.  We are still working out the proper format
of the JSON entries of the version information and should hopefully have
an agreement of how to do this early next week, as the logic there isn't
exactly "simple".

If the announcement format needs additional work, please let us know.

thanks,

greg k-h