[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <288132ea-87cf-4b56-908e-2263b6c6b67f@redhat.com>
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