[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024021602-unaudited-consoling-be37@gregkh>
Date: Fri, 16 Feb 2024 08:41:31 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: Michal Hocko <mhocko@...e.com>, corbet@....net,
workflows@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, security@...nel.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 11:40:43AM -0800, Kees Cook wrote:
> On Thu, Feb 15, 2024 at 07:20:09PM +0100, Greg Kroah-Hartman wrote:
> > 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
> > ...
> > the latest release is impossible, the individual change to resolve this
> > issue can be found at:
> > https://git.kernel.org/stable/linux/c/f08adf5add9a071160c68bb2a61d697f39ab0758
>
> This is the "original fix", a v5.16 commit, which was backported to all
> the stables. For this case, that seems fine (it's pretty easy to grep
> the stable trees for the SHA).
>
> In the case of a fix only being in -stable, what will be listed for
> SHAs here? Each stable SHA? Something else?
I think listing all of the SHA values, stable and mainline, would be
best, right? No need for everyone to try to grep the trees, and bonus,
the json format has a specific field just for this as well. That's on
my todo list for today...
thanks,
greg k-h
Powered by blists - more mailing lists