Re: [PATCH] SUNRPC: Add a check for gss_release_msg

[Leon Romanovsky]

On Fri, Apr 23, 2021 at 05:48:50PM -0400, J. Bruce Fields wrote:
> Have umn addresses been blocked from posting to kernel lists?

It is very unlikely.

> 
> Anyway:
> 
> On Fri, Apr 23, 2021 at 10:29:52PM +0300, Leon Romanovsky wrote:
> > On Fri, Apr 23, 2021 at 02:07:27PM -0400, J. Bruce Fields wrote:
> > > On Fri, Apr 23, 2021 at 08:25:28PM +0300, Leon Romanovsky wrote:
> > > > On Thu, Apr 22, 2021 at 03:39:50PM -0400, J. Bruce Fields wrote:
> > > > > On Wed, Apr 21, 2021 at 09:56:37AM -0400, J. Bruce Fields wrote:
> > > > > > On Wed, Apr 21, 2021 at 04:49:31PM +0300, Leon Romanovsky wrote:
> > > > > > > If you want to see another accepted patch that is already part of
> > > > > > > stable@, you are invited to take a look on this patch that has "built-in bug":
> > > > > > > 8e949363f017 ("net: mlx5: Add a missing check on idr_find, free buf")
> > > > > > 
> > > > > > Interesting, thanks.
> > > > > 
> > > > > Though looking at it now, I'm not actually seeing the bug--probably I'm
> > > > > overlooking something obvious.
> > > > 
> > > > It was fixed in commit 31634bf5dcc4 ("net/mlx5: FPGA, tls, hold rcu read lock a bit longer")
> > > 
> > > So is the "Fixes:" line on that commit wrong?  It claims the bug was
> > > introduced by an earlier commit, ab412e1dd7db ("net/mlx5: Accel, add TLS
> > > rx offload routines").
> > 
> > Yes, I think that Fixes line is misleading.
> > 
> > > 
> > > Looks like Aditya Pakki's commit may have widened the race a little, but
> > > I find it a little hard to fault him for that.
> > 
> > We can argue about severity of this bug, but the whole paper talks about
> > introduction of UAF bugs unnoticed.
> 
> Aditya Pakki points out in private mail that this patch is part of the
> work described in this paper:
> 
> 	https://www-users.cs.umn.edu/~kjlu/papers/crix.pdf
> 
> (See the list of patches in the appendix.)
> 
> I mean, sure, I suppose they could have created that whole second line
> of research just as a cover to submit malicious patches, but I think
> we're running pretty hard into Occam's Razor at that point.

Let's not speculate here.

The lack of trust, due to unethical research that was done by UMN researchers,
amount of bugs already introduced by @umn, and multiple attempts to repeat the
same pattern (see Al Viro responses on patches like this SUNRPC patch) is enough
to stop waste our time.

Thanks

> 
> --b.