Date: Wed, 21 Feb 2024 19:09:52 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sasha Levin <sashal@...nel.org>
Cc: linux-kernel@...r.kernel.org, cve@...nel.org,
 Greg Kroah-Hartman <gregkh@...uxfoundation.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 17:22, Sasha Levin wrote:
> On Wed, Feb 21, 2024 at 04:56:31PM +0100, Paolo Bonzini wrote:
>>> So now you're asking us to drop this additional work on them by
>>> reviewing CVE requests?
>>
>> It doesn't have to be mandatory.  But for people that _do_ want to do
>> the work, they might as well do it before the CVE is publicly announced,
>> rather than after.  At least give us the possibility of doing it without
>> bureaucracy.
> 
> [...]
> 
>>> How were you aware until a few weeks ago where CVE assignments were
>>> handled by different entities?
>>
>> They more often than not CC'd me before the patch was committed and
>> provided me the CVE id, and I was able to provide input or dispute the
>> assignment beforehand.  This is exactly what I'm suggesting that the
>> kernel should do.
> 
> This is fascinating to know, because when multiple members of the
> community asked to review CVEs before they are assigned, certain few
> CNAs blatantly ignored such requests.
>
> Would you want to expand on why you got the courtesy of being able to
> review these assignments, while the rest of us had to jump through the
> hoops of becoming our own CNA just to stop from this crap from happening
> to us?

Probably because I generally get CVEs myself ahead of time for 
corruption or use-after-free bugs (in arch-independent or x86 KVM code). 
  So when somebody comes with a CVE it's usually Project Zero stuff and 
not something like CVE-2024-0562, and we work together.

If you can tell me (even privately) what CNAs these were, I can check. 
But probably the answer is simply that either they have never touched 
KVM, or the issues were under some kind of embargo.

>>> So yes, I disagree with your "all of them" statement. For that matter,
>>> I'd argue that the number of users who need massaged messages are the
>>> vast minority.
>>
>> They don't need massaged messages.  They need correct and complete ones.
>> You're completely removing the human part of the work and expecting
>> the result to be of comparable quality.  That's not going to happen, and
>> this CVE is an example of this.
> 
> I definitely agree that it would be nice to have better messages in
> CVEs, and I'd welcome interested parties to follow the process that was
> in place up until two weeks ago, and request an amendment to a CVE with
> a better description (or dispute an invalid one) with the CNA.
> This is exactly the same process that most of us had to follow in the
> past to address crappy CVE descriptions or bogus CVEs.

And what I am saying is that we need to do better.  Give the maintainer 
an opportunity to say at least yes or no.

>>>> 2) how are you going to handle patch dependencies?  Are they going to
>>>> be rolled into a single entry or split into multiple announcements?
>>>
>>> Likely multiple different entries.
>>
>> So, looking at
>> https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/review/6.7.proposed
>> I see
>>
>> aeb686a98a9e usb: gadget: uvc: Allocate uvc_requests one at a time
>> da324ffce34c usb: gadget: uvc: Fix use-after-free for inflight 
>> usb_requests
>>
>> What vulnerability is the first one fixing?  Looking at your GSD
> 
> Well, if you look at the first patch, it says "This patch is 1 of 2
> patches addressing the use-after-free issue.".

Right, it's *the* issue.  It's one CVE, not two.  The first patch is a 
dependency of the actual fix, it's not its own vulnerability.

>> entries, will there even be CVEs purporting that renaming a variable
>> from "foo" to "bar" is fixing a vulnerability?
> 
> Maybe? Hopefully not if it's not a real security issue.

What if it's a dependency of the actual issue/fix?

>> I like to assume the best of people, so I'll assume that this is just
>> naïveté rather than an intentional attempt at burning everything down.
>> But please, let's take a step back and understand what the proposed
>> workflow fixes and breaks for everyone (especially maintainers and
>> distros).  Then make a proper solution.  In the meanwhile you can keep
>> sending test announcements to linux-cve-announce, and those can be used
>> to debug the process and the scripts.
> 
> No objections on future improvements, right now we're still trying to
> get the basics working which is where the strong pushback on "feature
> requests" is coming from.

Got it.  But multiple commits per CVE is not a feature request, it's 
basic acknowledgement of how Linux is developed.

>> In fact it would be nice if bippy included at the end the command line
>> that was used, to aid the reproduction and fixing of bugs.
> 
> Bippy just maps commits to trees and formats the json, or did I
> misunderstand what you meant?

I would like to run bippy myself to understand how the commits in 
CVE-2023-52437 were chosen.

Paolo

Powered by blists - more mailing lists