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 11:48:46 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Anna Schumaker <anna.schumaker@...app.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Aditya Pakki <pakki001@....edu>,
        Chuck Lever <chuck.lever@...cle.com>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Dave Wysochanski <dwysocha@...hat.com>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        netdev@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] SUNRPC: Add a check for gss_release_msg

On Wed, Apr 21, 2021 at 05:15:26PM +0300, Leon Romanovsky wrote:
> > This thread is the first I'm hearing about this. I wonder if there is
> > a good way of alerting the entire kernel community (including those
> > only subscribed to subsystem mailing lists) about what's going on? It
> > seems like useful information to have to push back against these
> > patches.
> 
> IMHO, kernel users ML is good enough for that.

The problem is that LKML is too high traffic for a lot of people to
want to follow.

There are some people who have used the kernel summit discuss list
(previously ksummit-discuss@...ts.linux-foundation.org, now
ksummit@...ts.linux.dev) as a place where most maintainers tend to be
subscribed, although that's not really a guarantee, either.  (Speaking
of which, how to handle groups who submit patches in bad faith a good
Maintainer Summit topic for someone to propose...)

To give the devil his due, Prof. Kangjie Lu has reported legitimate
security issues in the past (CVE-2016-4482, an information leak from
the kernel stack in the core USB layer, and CVE-2016-4485, an
information leak in the 802.2 networking code), and if one looks at
his CV, he has a quite a few papers in the security area to his name.

The problem is that Prof. Lu and his team seem to be unrepentant, and
has some very... skewed... ideas over what is considered ethical, and
acceptable behavior vis-a-vis the Kernel development community.  The
fact that the UMN IRB team believes that what Prof. Lu is doing isn't
considered in scope for human experimentation means that there isn't
any kind of institutional controls at UMN for this sort of behavior
--- which is why a University-wide Ban may be the only right answer,
unfortunately.

					- Ted