Message-ID: <7be9ad00-1432-4a19-a954-32fa0f24fecd@redhat.com>
Date: Thu, 22 Feb 2024 14:31:06 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 2/22/24 13:55, Greg Kroah-Hartman wrote:
>> 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 :)

Now we're talking. :)

>> 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.

Well, LKML is not the most searchable archive and subscribing to it puts 
measurable stress on the kernel.org servers (mostly due to gmail 
shenanigans, but still).

Plus (relatively) fine grained mailing lists are really cheap to 
subscribe to lore/NNTP.  So if the reply-to points to LKML + the 
subsystem mailing list for the maintainers + a new ML for the security 
folks (and these three are also CC'd on the announcements, at least the 
last two), that would be nice to have.  I can work on patches to 
vulns.git, for example to integrate with get_maintainer.pl, if you ack 
the idea.

The linux-cve@ mailing list would also be a natural place to send 
patches to vulns.git.

>> 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!

Would be nice to have that documented.  Again, I can put everything in 
words once we have some agreement.

>> 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.

Wait that's not what the docs say:

+If anyone wishes to
+have a CVE assigned before an issue is resolved with a commit, please
+contact the kernel CVE assignment team at <cve@...nel.org> to get an
+identifier assigned from their batch of reserved identifiers.

>> * should it be acked by the subsystem maintainer
> 
> Not needed, but sure, if you want to.

Ok, then we should add something to that end in the docs as well, 
suggesting Cc of the maintainers.

>> 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.

Well, it's different in that it will at least double the CVEs processed 
every year (potentially more---if we go by the number of GSD entries, 
it's more like 5x), and the delta will be coming from one CNA only.

So it's just that it's a lot of new work.  So far the only thing for 
which I can say "this sucks" is having one CVE per commit in a 
multi-patch fix.  That's somewhat ingrained in the operation of the 
bippy script, but not unfixable (and BTW I wouldn't mind rewriting bippy 
in Python, but that's a different story).

> 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.

Lol yeah I've seen some of those too (but only this morning---I'm not 
writing on their behalf, in case that was unclear).

Paolo

> 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