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

[Sasha Levin]

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.

No objections that commit messages aren't perfect, they're just better
than the some unhelpful text like:

"""
In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.
"""

My choice was to actually just call out the offending commit and be done
with it, without additional description.

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

[ snip ]

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

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

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

> > > 3) are the scripts used to generate the CVEs public?  Can fixes to the
> > > scripts be developed in the open?
> >
> > Yup - https://git.kernel.org/pub/scm/linux/security/vulns.git/ .
>
> What about the detection part?

Manual at this point, we're looking into converging workflows but it's
one of those things we'd need to address after we got the basics in
place.

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

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

--
Thanks,
Sasha