Re: [RFC][PATCH] make sure that lock_for_kill() callers drop the locks in safe order

Jeff Layton
2026-04-10T19:32:48Z

On Fri, 2026-04-10 at 20:19 +0100, Al Viro wrote:
> On Fri, Apr 10, 2026 at 02:21:39PM -0400, Jeff Layton wrote:
>
> > I've not been able to reproduce the UAF at all.
> >
> > It was possible to reproduce the hang that we were seeing by injecting
> > an mdelay() just after the cond_resched() in __dentry_kill(), but Al's
> > other series seems to have fixed that.
>
> Elimination of busy-wait is likely to hide whatever's going on, so it
> shouldn't be there when hunting for reproducer.
>

This was before that. I know Gustavo also tried to reproduce it and he
was able to hit the hang but no UAF.

> > The UAF seems to be dependent on those hangs somehow, but we were never
> > able to get one to fire from a reproducer attempt. They just
> > occasionally pop up when these stalls occur.
>
> Not even with mdelay() stuck in there? FWIW, another UAF report in the
> same general area is parisc buildd running into that when building
> a specific package (webkit2gtk); Debian kernels 6.16..6.19 (at least),
> no idea which config it is...

Yep, not even with that. One thing that claude pointed out: doing an
mdelay() might prevent it from making any progress freeing dentries.
I'm experimenting now with one that only randomly does a delay, but so
far that hasn't turned up anything. I'll let you know if that changes.

--
Jeff Layton <jlayton@kernel.org>