Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS

[Greg KH <greg () kroah com>]

On Thu, Mar 18, 2021 at 08:21:36PM +0100, Solar Designer wrote:
> Greg, I'd appreciate you not repeating the same things over and over -
> such as (roughly) "who is this for" and "why did you assign this CVE
> _now_".  Questioning CVE assignment is reasonable and desirable, but
> only when that is specific (e.g., point out specific reasons why you
> think an issue might not be CVE worthy) and not generic (questioning
> every CVE without giving reasons, or asking why bother with CVE for an
> old issue).  As a moderator, I tell you that the kind of messages Red
> Hat is posting _are_ desirable in here.  They could be more detailed,
> and it's OK to ask for more detail, but it's not OK to discourage their
> posting.  Thank you.

If you look at the 3 RH emails this week for issues, they all contained
misinformation and confused people.  I did not do my usual "why are you
asking for a CVE for an old issue" questions, I asked in one for more
information about the issue involved, and for the other, proper
acknowledgment for the people that reported and fixed the issue as what
was written was entirely incorrect and ignored them.

I asked for that _because_ once these types of "announcements" go out to
the world, my inbox instantly starts filling up with "why isn't this
fixed in a stable kernel." "please tell me what commit fixes this
issue." and the like from users of Linux.  Because the CVE notices are
all still marked "private", doing misleading announcements like this
cause a mini DoS on a number of kernel community members each time.

So until Red Hat starts sending out announcements that are actually
correct and are helpful to the community, I will keep complaining,
because they directly affect me and others that work upstream on the
stable kernel releases.

For an example of how to do a "good" CVE notice, I will point out
Piotr's excellent emails today for CVE-2020-27171 and CVE-2020-27170.
Red Hat could use those as a template of how to write their
announcements in a way that would be useful for us all, and would _not_
cause the upstream kernel developers additional work.

thanks,

greg k-h