lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YIAy1tH0miFxEJEk@unreal>
Date:   Wed, 21 Apr 2021 17:12:38 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc:     Trond Myklebust <trondmy@...merspace.com>,
        "a.shelat@...theastern.edu" <a.shelat@...theastern.edu>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "chuck.lever@...cle.com" <chuck.lever@...cle.com>,
        "dwysocha@...hat.com" <dwysocha@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "sudipm.mukherjee@...il.com" <sudipm.mukherjee@...il.com>,
        "bfields@...ldses.org" <bfields@...ldses.org>,
        "anna.schumaker@...app.com" <anna.schumaker@...app.com>,
        "pakki001@....edu" <pakki001@....edu>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] SUNRPC: Add a check for gss_release_msg

On Wed, Apr 21, 2021 at 03:50:58PM +0200, gregkh@...uxfoundation.org wrote:
> On Wed, Apr 21, 2021 at 04:34:00PM +0300, Leon Romanovsky wrote:
> > On Wed, Apr 21, 2021 at 03:21:15PM +0200, gregkh@...uxfoundation.org wrote:
> > > On Wed, Apr 21, 2021 at 01:11:03PM +0000, Trond Myklebust wrote:
> > > > On Wed, 2021-04-21 at 15:19 +0300, Leon Romanovsky wrote:
> > > > > On Wed, Apr 21, 2021 at 11:58:08AM +0000, Shelat, Abhi wrote:
> > > > > > > > 
> > > > > > > > > > They introduce kernel bugs on purpose. Yesterday, I took a
> > > > > > > > > > look on 4
> > > > > > > > > > accepted patches from Aditya and 3 of them added various
> > > > > > > > > > severity security
> > > > > > > > > > "holes".
> > > > > > > > > 
> > > > > > > > > All contributions by this group of people need to be
> > > > > > > > > reverted, if they
> > > > > > > > > have not been done so already, as what they are doing is
> > > > > > > > > intentional
> > > > > > > > > malicious behavior and is not acceptable and totally
> > > > > > > > > unethical.  I'll
> > > > > > > > > look at it after lunch unless someone else wants to do it…
> > > > > > > > 
> > > > > > 
> > > > > > <snip>
> > > > > > 
> > > > > > Academic research should NOT waste the time of a community.
> > > > > > 
> > > > > > If you believe this behavior deserves an escalation, you can
> > > > > > contact the Institutional Review Board (irb@....edu) at UMN to
> > > > > > investigate whether this behavior was harmful; in particular,
> > > > > > whether the research activity had an appropriate IRB review, and
> > > > > > what safeguards prevent repeats in other communities.
> > > > > 
> > > > > The huge advantage of being "community" is that we don't need to do
> > > > > all
> > > > > the above and waste our time to fill some bureaucratic forms with
> > > > > unclear
> > > > > timelines and results.
> > > > > 
> > > > > Our solution to ignore all @umn.edu contributions is much more
> > > > > reliable
> > > > > to us who are suffering from these researchers.
> > > > > 
> > > > 
> > > > <shrug>That's an easy thing to sidestep by just shifting to using a
> > > > private email address.</shrug>
> > > 
> > > If they just want to be jerks, yes.  But they can't then use that type
> > > of "hiding" to get away with claiming it was done for a University
> > > research project as that's even more unethical than what they are doing
> > > now.
> > > 
> > > > There really is no alternative for maintainers other than to always be
> > > > sceptical of patches submitted by people who are not known and trusted
> > > > members of the community, and to scrutinise those patches with more
> > > > care.
> > > 
> > > Agreed, and when we notice things like this that were determined to be
> > > bad, we have the ability to easily go back and rip the changes out and
> > > we can slowly add them back if they are actually something we want to
> > > do.
> > > 
> > > Which is what I just did:
> > > 	https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> > 
> > Greg,
> > 
> > Did you push your series to the public git? I would like to add you a
> > couple of reverts.
> 
> Yes, it can be found here:
> 	git@...olite.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-core.git umn.edu-reverts
> 
> You can send reverts in email if you want, whatever works best.
> 
> > And do you have a list of not reverted commits? It will save us from
> > doing same comparison of reverted/not reverted over and over.
> 
> Below is the list that didn't do a simple "revert" that I need to look
> at.  I was going to have my interns look into this, there's no need to
> bother busy maintainers with it unless you really want to, as I can't
> tell anyone what to work on :)

Ohh, you have interns, so even better.

Thanks

> 
> thanks,
> 
> greg k-h
> 
> -------------------------
> # commits that need to be looked at as a clean revert did not work
> 990a1162986e
> 58d0c864e1a7
> a068aab42258
> 8816cd726a4f
> c705f9fc6a17
> 8b6fc114beeb
> 169f9acae086
> 8da96730331d
> f4f5748bfec9
> e08f0761234d
> cb5173594d50
> 06d5d6b7f994
> d9350f21e5fe
> 6f0ce4dfc5a3
> f0d14edd2ba4
> 46953f97224d
> 3c77ff8f8bae
> 0aab8e4df470
> 8e949363f017
> f8ee34c3e77a
> fd21b79e541e
> 766460852cfa
> 41f00e6e9e55
> 78540a259b05
> 208c6e8cff1b
> 7ecced0934e5
> 48f40b96de2c
> 9aabb68568b4
> 2cc12751cf46
> 534c89c22e26
> 6a8ca24590a2
> d70d70aec963
> d7737d425745
> 3a10e3dd52e8
> d6cb77228e3a
> 517ccc2aa50d
> 07660ca679da
> 0fff9bd47e13
> 6ade657d6125
> 2795e8c25161
> 4ec850e5dfec
> 035a14e71f27
> 10010493c126
> 4280b73092fe
> 5910fa0d0d98
> 40619f7dd3ef
> 0a54ea9f481f
> 44fabd8cdaaa
> 02cc53e223d4
> c99776cc4018
> 7fc93f3285b1
> 6ae16dfb61bc
> 9c6260de505b
> eb8950861c1b
> 46273cf7e009
> 89dfd0083751
> c9c63915519b
> cd07e3701fa6
> 15b3048aeed8
> 7172122be6a4
> 47db7873136a
> 58f5bbe331c5
> 6b995f4eec34
> 8af03d1ae2e1
> f16b613ca8b3
> 6009d1fe6ba3
> 8e03477cb709
> dc487321b1e6

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ