oss-security - Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 19 Mar 2021 15:58:25 -0400
From: Brad Spengler <spender@...ecurity.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

Hi Sasha,

> I'm really not sure how to respond to this. I don't own upstream, my
> name isn't Linus, Greg, nor do I maintain a major subsystem. I don't
> have any control over how upstream commits look like.

Both you and Greg certainly have control over stable kernel commit
messages (it's the same ability you use to add the upstream commit ID).
Greg at least receives private notification of security vulnerabilities
through security@...nel.org.  I've privately received several complaints
from different researchers about what was lacking from commit messages
for vulnerabilities they reported there.

> Can you please stop complaining about Greg's mails as if I was the one
> who wrote them? I'm not his alter-ego, twin, or so on. If you have a
> concern with what he writes take it up with him.

I wanted to avoid having to send multiple mails to the mailing list
and cluttering it up even more (which is now unavoidable).

But since I'm here, I'll also address an assertion Greg repeated today:
https://seclists.org/oss-sec/2021/q1/242
that RH had incorrectly credited the CVE, after it had been already
pointed out here:
https://seclists.org/oss-sec/2021/q1/225
that the reporter had found a flaw in the backport of the original
fix that had happened years ago.  This is not improper acknowledgement.
If Greg wanted to ensure proper acknowledgement of a CVE for the *original*
issue, he could have done that back in 2018 when he committed the
original fix:

commit 3d63b7e4ae0dc5e02d28ddd2fa1f945defc68d81
Author:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
AuthorDate: Sat May 26 09:53:13 2018 +0900
Commit:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CommitDate: Thu Jun 28 21:30:16 2018 +0900

    n_tty: Fix stall at n_tty_receive_char_special().

I'm in agreement that since the flaw was in the backport, it should have
been attributed to RHEL, BTW.

> Great, let's work together on making it better, but it's been following
> the same pattern for quite a while now.

I think both you and Greg are exaggerating the level of "extra work" this
temporary blip creates for you -- with the exception of the RH backport
issue, it was not difficult at all for me to determine what issue was
being discussed, without even having to plug the CVEs into bugzilla.redhat.com
which produces:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-35519
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2021-3428
(though these are equally light on information)

Greg's annoyances on this list have been going on for far longer than these
recent advisories, and are not specific even to RH advisories.  For instance,
in the middle of his RH tirade, he posted this useless email about another
set of issues:
https://seclists.org/oss-sec/2021/q1/217
It's not the concern of the list why the reporter did or did not provide the
fixes upstream (at least two of which were already upstreamed).

We do not need more emails from Greg like:
https://seclists.org/oss-sec/2021/q1/21
"I still do not understand why you report issues that are fixed over a year ago"
"Who does this help out"

https://seclists.org/oss-sec/2021/q1/100
"5.1.0 is _VERY_ old"

https://seclists.org/oss-sec/2021/q1/233
"Is that a mistake in your kernel development process that should be
resolved?"

They are as useless to this list as his boilerplate "all users must upgrade"
stable announcements every 3 days.

I'm hopeful that RH's advisories will return to their previous level of
information (not "start" as Greg characterized it).  What can be said of
upstream's policies that everyone's been putting up with for ~16 years now?

Thanks,
-Brad

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

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.