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]

Message-ID: <YFNCtWmsYrtYQeEJ@kroah.com>
Date: Thu, 18 Mar 2021 13:08:21 +0100
From: Greg KH <greg@...ah.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

On Thu, Mar 18, 2021 at 05:03:53PM +0530, Rohit Keshri wrote:
> Hello Team,
> 
> > Given that the above CVE is not public in any database that I can find,
> > one can only hope that the text will reflect what really is happening
> > here.  Rohit, why was this even published?
> 
> > Again, stuff like this is just causing extra work by everyone else for
> > no good reason that I can see.
> 
> 
> I understand and apologize for the confusion.
> 
> 
> This issue was reported for rhel7 to us (which was not seen in rhel8
> or later versions),  but it also  applies to  kernel before this
> ('3d63b7e4ae0dc') patch or kernel without this patch.
> 
> 
> $ git tag --contains  3d63b7e4ae0dc
> v4.18
> v4.18-rc3
> v4.18-rc4
> v4.18-rc5
> v4.18-rc6
> v4.18-rc7
> v4.18-rc8
> 
> ..

`git describe` should be used instead for stuff like this:
	$ git describe --contains 3d63b7e4ae0dc
	v4.18-rc3~4^2~4

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

So this means that your RHEL 7 kernel, which is based on 3.10, somehow
missed picking this up when it was backported to the "newer" stable
kernel trees almost 3 years ago.

Is that a mistake in your kernel development process that should be
resolved?

> 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.

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.

So, what really is your goal here?

thanks,

greg k-h

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.