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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@linuxfoundation.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@chromium.org>
> > > > 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>
> > > > ---
> > > > 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