Date: Thu, 22 Feb 2024 10:58:22 +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/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

* if and how anyone else could propose them

* whether the CVE team can also do them unilaterally

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.

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.

Another underspecified part is the early request of CVEs.  Some 
questions I have:

* what information is needed

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

* should it be acked by the subsystem maintainer

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.

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.

In the meanwhile, you already have the benefit of coordinating the 
creation of CVEs, avoiding surprises like CVE-2024-0562 and allowing the 
modifications.

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

Paolo

Powered by blists - more mailing lists