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

[Greg Kroah-Hartman]

Sorry for the delay in response, been a busy week...

On Thu, Feb 22, 2024 at 02:31:06PM +0100, Paolo Bonzini wrote:
> > > Perhaps since there's no archive for cve@xxxxxxxxxx, there should be a
> > > public discussion mailing list (e.g. linux-cve@vger) that maintainers can
> > > reply to?  The private cve@xxxxxxxxxx alias would then be just for the
> > > request of embargoed CVEs.
> > 
> > What's wrong with lkml for discussion?  I'll add a "reply-to" to point
> > there as well so that it will properly redirect if you respond to a
> > message sent to the -announce list.
> 
> Well, LKML is not the most searchable archive and subscribing to it puts
> measurable stress on the kernel.org servers (mostly due to gmail
> shenanigans, but still).

lore is a great search tool for lkml, and you can subscribe to feeds
from it very easily.

> Plus (relatively) fine grained mailing lists are really cheap to subscribe
> to lore/NNTP.

Lore picks out stuff from lkml just as easily.

> So if the reply-to points to LKML + the subsystem mailing
> list for the maintainers + a new ML for the security folks (and these three
> are also CC'd on the announcements, at least the last two), that would be
> nice to have.  I can work on patches to vulns.git, for example to integrate
> with get_maintainer.pl, if you ack the idea.

That might be a bit noisy, for some commits, but sure, I can see the
value in being notified about a CVE for my subsystem.  If you have a
specific 'get_maintainer.pl' command line invocation you think would be
good, I can easily add it to the scripts.

> The linux-cve@ mailing list would also be a natural place to send patches to
> vulns.git.

Proliferation of mailing lists are a pain, I'd like to resist that for
now if possible.  Just use lkml and cc: cve@xxxxxxxxxx if you want to
send us patches.

> > > * is there a limit on embargo length similar to security@xxxxxxxxxx
> > 
> > We have no embargos here, you should NOT be emailing this alias about
> > any unfixed security things, the document explicitly states this.
> 
> Wait that's not what the docs say:
> 
> +If anyone wishes to
> +have a CVE assigned before an issue is resolved with a commit, please
> +contact the kernel CVE assignment team at <cve@xxxxxxxxxx> to get an
> +identifier assigned from their batch of reserved identifiers.

The document also says:
	If you feel you have found an unfixed security issue, please
	follow the :doc:`normal Linux kernel security bug reporting
	process<../process/security-bugs>`.

So _IFF_ you have an unfixed security issue that security@k.o knows
about, and you MUST have a CVE id at this point in time (i.e. because it
needs to be referenced somewhere), then you can email cve@k.o to get
one, but the number of times I forsee that being the case based on the
security@k.o workload is going to be very small.

So we can take those on a case-by-case basis please, that's not going to
be a normal occurrence.

> So it's just that it's a lot of new work.  So far the only thing for which I
> can say "this sucks" is having one CVE per commit in a multi-patch fix.
> That's somewhat ingrained in the operation of the bippy script, but not
> unfixable (and BTW I wouldn't mind rewriting bippy in Python, but that's a
> different story).

Yes, the "multi-patch" issue is going to be real, and we will handle it
when it happens.  The current scripts don't handle that well, but they
DO allow us to hand-write entries, which is probably what is going to
happen for those types of rare issues.

And yes, bippy in Python would be nice, but my python skills are bad
(and you didn't want me writing it in perl), so I went with what I could
do in the amount of time I had to get it up and running.

> > I've already had soo many threads from the "Red Hat product security
> > team" including flow charts and other fun things to last me quite a
> > while already, and that's just in the past few days.
> 
> Lol yeah I've seen some of those too (but only this morning---I'm not
> writing on their behalf, in case that was unclear).

I met with someone from Red Hat earlier this week and hopefully most of
this will be resolved soon, I'm waiting to hear back from them for the
issues we discussed.

thanks,

greg k-h