Have umn addresses been blocked from posting to kernel lists?
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.
--b.
