Re: CVE-2023-52437: Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"

[Paolo Bonzini]

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