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 18:49:59 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Oleksandr Natalenko <oleksandr@...alenko.name>
Cc: Lukas Bulwahn <lukas.bulwahn@...il.com>, 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 05:10:50PM +0100, Oleksandr Natalenko wrote:
> Hello.
> 
> On čtvrtek 15. února 2024 13:04:56 CET Greg Kroah-Hartman wrote:
> > On Wed, Feb 14, 2024 at 09:34:38AM +0100, Lukas Bulwahn wrote:
> > > On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman
> > > <gregkh@...uxfoundation.org> 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>
> > > > 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>
> > > > ---
> > > > 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)
> > > >
> > > 
> > > Hi Greg, Sasha, Lee,
> > > 
> > > Generally, I think this is a great step forward on the whole "security
> > > vulnerability mess" and this will certainly help me and others in the
> > > embedded space to argue to update to recent stable kernel versions.
> > > This can then finally put the practice of shipping multiple-year-old
> > > kernel versions to an end. Often this was just done with the argument
> > > that there is not a recent CVE and fix assigned to some recent stable
> > > kernel version---and integrators think updates to recent kernel stable
> > > versions are not needed and not recommended.
> > > 
> > > I am looking forward to seeing what and how many stable commits are
> > > going to get CVEs assigned. If Greg's policy from the Kernel Recipes
> > > 2019 presentation comes into play, every git kernel hash (GKH)---at
> > > least in the stable tree---could get a CVE identifier (just to be on
> > > the safe side). But I assume you are going to use some expert
> > > knowledge, heuristics or some machine-learning AI to make some commits
> > > in the stable tree carrying a CVE identifier and some others not.
> > 
> > Yes, that "expert knowledge" will be "review all patches by hand" just
> > like we do today for all that are included in the stable trees.
> 
> Not undermining your efforts in any way, but I'd like to get an honest answer: is this really true? For instance,
> 
> $ git log --oneline v6.7.1..v6.7.2 | wc -l
> 641
> 
> Is it physically possible to actually review all these backports in just five days?

I did, yes.  And have been doing so for 15+ years, practice makes it
easier :)

thanks,

greg k-h