Message-ID: <2024022236-stock-wielder-fcbc@gregkh>
Date: Thu, 22 Feb 2024 13:55:18 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
	cve@...nel.org, Jiri Kosina <jkosina@...e.cz>
Subject: Re: CVE-2023-52437: Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING
 in raid5d"

On Thu, Feb 22, 2024 at 10:58:22AM +0100, Paolo Bonzini wrote:
> On 2/21/24 19:21, Greg Kroah-Hartman wrote:
> > On Wed, Feb 21, 2024 at 04:56:31PM +0100, Paolo Bonzini wrote:
> > > To recap:
> > > 
> > > - the CVE description comes from was upstream commit bed9e27baf52
> > > 
> > > - neither the CVE mitigation section nor the mentioned kernel releases
> > > fix the bug mentioned in the upstream commit, because the mitigation
> > > section also includes commits that _revert_ commit bed9e27baf52
> > > 
> > > - this second revert is not mentioned anywhere, so the CVE description
> > > is at best misleading; or perhaps more accurately described as
> > > "completely f***ed up".
> > > 
> > > I'm sure it's just a bug in the scripts, but it's worrisome that you
> > > don't acknowledge this.
> > 
> > Yes, this is a bug in the scripts, but it wasn't obvious what you were
> > objecting to here honestly.  Reverts were not anything I tested the
> > scripts with before now, and I'm sure there are going to be more cases
> > that fail in odd ways too.  We'll fix them when they show up, that's the
> > best we can do. [...]
> > 
> > If you want to replace the wording in the description here with anything
> > else better, PLEASE let us know and we will be glad to do so.
> 
> But there's not even a documented way to do it.
> 
> All that the document says is "the authority to dispute or modify an
> assigned CVE for a specific kernel change lies solely with the maintainers
> of the relevant subsystem affected".  But it doesn't say:
> 
> * how the maintainer would ask for such a modification or dispute

Email.

> * if and how anyone else could propose them

Email.

> * whether the CVE team can also do them unilaterally

Yup, through email :)

> Perhaps since there's no archive for cve@...nel.org, there should be a
> public discussion mailing list (e.g. linux-cve@...r) that maintainers can
> reply to?  The private cve@...nel.org alias would then be just for the
> request of embargoed CVEs.

What's wrong with lkml for discussion?  I'll add a "reply-to" to point
there as well so that it will properly redirect if you respond to a
message sent to the -announce list.

> It would be great if modifications or disputes could simply be sent as
> patches to the vulns.git repo.  You guys can have push hooks or something
> like that that take care of sending messages to linux-cve-announce etc.

Yes, I'll gladly take that as well!

> Another underspecified part is the early request of CVEs.  Some questions I
> have:
> 
> * what information is needed

What ever information you feel is necessary.  What would you do if you
had to make up your mind on this?

At the minimum, a git id :)

> * is there a limit on embargo length similar to security@...nel.org

We have no embargos here, you should NOT be emailing this alias about
any unfixed security things, the document explicitly states this.

Funnily enough, one major Linux vendor has already done just that, and
exposed the fact that they were getting leaked information sent to them
and possibly an embargo is now broken.

The fallout of this is going to be "interesting".

> * should it be acked by the subsystem maintainer

Not needed, but sure, if you want to.

> More in general, I think you're underestimating the extra work for the
> "listeners" of CVEs, that will come from bugs in the script or other
> not-so-well-defined aspects of the process.  I really think it would be a
> good idea to behave "as if" you were already creating CVE, but for now just
> send out the announcements and publish the JSON in a git repo.

How is it any different from the existing "listeners" of CVEs today?  in
fact, it's a world better as the meta-data we are now providing in the
json files is so much better than all of the crud that all of the other
CNAs were putting in there, it's not even a fair comparison.

So far some vendors have said "this is great!"  No one has said "this
sucks", but if you know of any, let us know, and we will be glad to
adjust the information published as needed.

> As we run the experiment for a while, we can get input from interested
> maintainers and third parties.  I am sure I can find someone from the Red
> Hat product security team to explain their desires, clarify how they consume
> CVE announcements, and what simplifies/complicates their job. Their needs
> are probably not that unique.

I've already had soo many threads from the "Red Hat product security
team" including flow charts and other fun things to last me quite a
while already, and that's just in the past few days.

Given that the "Red Hat product security team" was the #1 offender in
creating CVEs against the kernel that caused us so much work and
headaches that it pushed me over the edge to go through all of the extra
work to actually become a CNA, I think it's worth considering what you
are asking for here.

In other words, they know how to contact us, before, we could never
contact them.  This is up to them to decide how to interact, not us.
And remember, the number of RH systems that that team affects is pretty
much in the rounding error of the other Linux systems out there, not
that I'm counting or anything, just saying :)

> > That's the benifit of being a CNA, we can ACTUALLY MODIFY the CVE
> > records, previously it was almost impossible to ever do so.
> 
> Agreed.  There is potential to do much better than before.

Totally agreed, thanks for the questions!

greg k-h

Powered by blists - more mailing lists