[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Mar 2021 20:21:36 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS
Hi,
FWIW, I agree with what Kurt H Maier wrote. While I wish Red Hat's
messages like these were more informative right away, Greg's messages
are unfortunately beyond being purely constructive and are in part
discouraging. We're lucky that so far his requests for more information
actually resulted in just that, and didn't result in Red Hat stopping to
post - that is, that others replying had the strength to interpret them
constructively despite of their tone suggesting otherwise. OTOH, we
have no way to know whether someone was actually discouraged enough not
to post on some occasion.
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.
On Thu, Mar 18, 2021 at 02:33:21PM -0400, Sasha Levin wrote:
> On Thu, Mar 18, 2021 at 10:19:31AM -0700, Kurt H Maier wrote:
> >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.
>
> I think that this is an excellent point: RedHat shouldn't be reporting
> issues for "Linux Kernel" then. Look at the subject of this mail:
>
> CVE-2021-20219 Linux kernel: improper synchronization in
> flush_to_ldisc() can lead to DoS
>
> It doesn't say "Red Hat Linux kernel", it just says "Linux kernel",
> right?
>
> Red Hat runs on a forked version of the kernel that has it's own set of
> backports, features, and bugs. As you pointed out I think it would make
> a lot of sense if they would instead start assigning CVEs for "Red Hat
> Linux Kernel".
Oh, no. Just no. Red Hat (nor others) shouldn't start to
indiscriminately label their CVE assignments for Linux kernel issues
(nor for issues in other software they modify and package) like that.
I think what we really want is encourage Red Hat (and other distros) to
put more effort into figuring out and documenting whether each issue is
specific to them or (was) also present in mainline (any version or git
commit, but not requiring a review of any branches other than what they
possibly took code from). I think they usually already have that
information internally. It's just that it didn't propagate into this
thread's original message now. It should.
Then, for issues that (ever) exist(ed) in upstream kernels, or in any
upstream Open Source software for that matter, they should be brought to
oss-security. It's very kind of a distro to help us all with that. We
should encourage that.
For issues that are distro-specific, it's a grey area. First, like you
correctly say, they should be labeled accordingly. Then the question of
their relevance to oss-security comes up. Among the published content
guidelines for oss-security we actually have one asking not to post in
here distro-specific advisories aimed at end-users. As I recall, when
at some point years ago FreeBSD started sending their advisories in
here, I asked them not to. Indeed, we're also not seeing e.g. Red Hat's
advisories in here, although they do produce those and send them to
proper channels. However, what about distro-specific vulnerability
notifications not meant for end-users, but for downstream distros?
Using my two examples, both FreeBSD and RHEL do have some downstream or
otherwise related distros, who might need to know to merge the fixes.
In fact, we have a reverse example of that in this same thread -
Virtuozzo had reported the issue to Red Hat presumably due to their
reuse of code from RHEL. It can happen both ways, and would also be
relevant to third-parties if there are more than two distros reusing
distro-specific code like that. It is quite possible that this thread
was also noticed and will be acted upon by some other RHEL kernel forks,
although chances are those monitor other Red Hat resources and would
have learned from there as well.
Alexander
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.
