[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YFOLo/QrlgIrFotJ@wopr>
Date: Thu, 18 Mar 2021 10:19:31 -0700
From: Kurt H Maier <khm@...ops.net>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE-2021-20219 Linux kernel: improper
synchronization in flush_to_ldisc() can lead to DoS
On Thu, Mar 18, 2021 at 01:08:21PM +0100, Greg KH wrote:
>
> But none of that takes into account for the backporting of commits into
> the stable tree, you need a different tool for that, which many of us
> have our own. If you use that you will see that the above commit really
> is in lots of fixed kernel trees:
>
> $ id_found_in 3d63b7e4ae0dc5e02d28ddd2fa1f945defc68d81
> 3.16.61 3.18.115 4.4.140 4.9.112 4.14.54 4.17.5 4.18
It's not really Red Hat's fault that there are six hundred "stable"
kernel versions, which each change approximately weekly. It's generally
not worth tracking, and it would not be sane to expect Red Hat to seek
or announce CVEs for git branches they don't maintain.
> > Since this issue was reported to us, identified as a security flaw,
> > and was fixed in the upstream, we decided to assign a CVE.
>
> But then you announce that CVE to the community with no context or
> information which only causes us to have to do lots of extra work.
They should have included the details which they later added, but I
can't even remember the last time Red Hat reported a kernel
vulnerability which contained enough information to satisfy you, so I
wouldn't really blame them if they gave up trying to please you.
> If it's Red Hat's goal to get some people in the Linux kernel community
> mad at them, it's working well. If it's Red Hat's goal to somehow help
> the community out with this type of announcement, it's not working at
> all. You failed to site the fix, when it was, who did the fix, who
> found the fix, and where it was actually fixed in, all things that
> people here actually would like to know.
Some people in the Linux kernel community seem to get mad as a hobby,
and measure their success by volume of email sent about it. Those of
us who administer Red Hat systems generally find the level of detail
sufficient and I for one appreciate Rohit's announcements. This one
could have been better, I agree.
Since MITRE set about destroying the CVE assignment process, reporting
of CVE assignments has been optional and to be frank we're lucky to get
this much these days.
> So, what really is your goal here?
What's yours? You don't seem to run RHEL, so why get bent out of shape
if they slip up while reporting a CVE assignment? I guess more
accurately, why get bent out of shape *every time* they report a CVE
assignment? Is it possible for you to just stop, so those of us who
find value in the reports don't have to page through all the complaining
in order to read it? Or is oss-security just doomed to the "greg is mad
at the email" cycle forever?
khm
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
