linux-kernel - Re: [PATCH] SUNRPC: Add a check for gss_release

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]

Date:   Wed, 21 Apr 2021 15:19:26 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     "Shelat, Abhi" <a.shelat@...theastern.edu>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Aditya Pakki <pakki001@....edu>,
        Chuck Lever <chuck.lever@...cle.com>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Dave Wysochanski <dwysocha@...hat.com>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] SUNRPC: Add a check for gss_release_msg

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.

Thanks