Re: [RFC PATCH v3 0/4] getting rid of busy-wait in shrink_dcache_parent()

Jeff Layton
2026-04-09T22:38:32Z

On Thu, 2026-04-09 at 22:57 +0100, Al Viro wrote:
> On Thu, Apr 09, 2026 at 04:10:41PM -0400, Jeff Layton wrote:
>
> > head_A ↔ UAF ↔ mountinfo(1) ↔ swaps(/) ↔ ... ↔
> > head_B(STACK) ↔ status(5962) ↔ exe(5962) ↔ ... ↔
> > stat(8808) ↔ ... ↔ mountinfo(1) ↔ UAF ↔ head_A
> > ```
>

I think the above is BS. Claude says:

In the earlier analysis I walked the list both forward from
head_B (the stack entry) and backward from head_A That was misleading
— there's only one mountinfo node. The ring passes through it once. The
duplicate in my listing was an artifact of walking the ring from two
entry points and not deduplicating.

> Wait a bloody minute; *two* UAF and two mountinfo there? Are the links
> in that cyclic list consistent? ->next and ->prev, I mean.

No:

The list was NOT a proper ring:

- FWD (head.next): LOOP at entry 1 — immediately hits a self-loop (the processed "status" dentry)
- BWD (head.prev): LOOP at entry 55 — walks 55 entries then hits a cycle

> If I understand the notation correctly... are there two different
> dentries, both with "mountinfo" for name and PROC_I(_->d_inode)->pid
> being PID 1? What are their ->d_parent pointing to? Are they hashed?
>
> > ### d_walk Escaped Its Starting Dentry
> > `d_walk` was called with `parent = /proc/4530/task/5964` (`data.start`
> > confirmed in stack frame). It should only traverse descendants of 5964.
> > But the dispose list contains entries from:
> > - `/proc/4530/task/5962/*` (151 children — sibling of 5964)
> > - `/proc/4530/task/6830`, `/proc/4530/task/8808` — other task entries
> > - `/proc/1/mountinfo`, `/proc/1/status`, `/proc/1/net` — PID 1 entries
> > - `/proc/sys/vm/overcommit_memory`, `/proc/sys/fs/*` — sysctl entries
> > - `/proc/pressure/{cpu,io,memory}` — PSI entries
> > - `/proc/swaps`, `/proc/cpuinfo`, `/proc/kcore` — root proc entries
>
> Not at all obvious; there's a list from another thread mixed into that,
> and we've no idea what had the root been for that one. For that matter,
> I'd check ->d_flags on the entries, just to verify that those are
> from shrink lists and not from LRU - the fact that these UAF still
> have pointers to plausible dentries does not mean they are from the
> same moment in time; if dentry in question had been on a different
> list before getting freed... That's why the question about ->prev
> and ->next consistncy.
>
> And seeing that procfs has zero callers of d_splice_alias() or d_move(),
> I would expect ->d_parent on all dentries in there to be constant over
> the entire lifetime; would be rather hard for d_walk() to escape in
> such conditions...

Definitely not legitimately. I suspect some other sort of mem
corruption. /proc/1/mountinfo is on the list though:

mountinfo dentries on dispose list: 1

/proc/1/mountinfo (dentry 0xffff88823deef800)
d_parent: 0xffff891373c06a80 "1" -> "/" (root)
hashed: yes (d_hash.pprev=0xffff893d337264d0)
PROC_I->pid nr: 3217077
d_inode: 0xffff88ea55a44508

Claude's theory (maybe garbage):

PID 1's mountinfo being on the list is actually a strong clue — it's
a dentry that would be on the global LRU (negative or zero-count
after someone closed /proc/1/mountinfo), and drop_caches would pull
it off the LRU via prune_dcache_sb. That's likely how it ended up on
Thread B's dispose list.

Here's a cursory comparitive analysis across the 3 vmcores I have so
far:

Comparative analysis across three vmcores
=========================================

Kernel 6.13.2-0_fbk5-hf2 6.13.2-0_fbk12-hf1 6.13.2-0_fbk5-hf2
Date Mar 31 Apr 9 Apr 2
Process SREventBase61 tokio-runtime-w TTLSFWorkerU151
d_invalidate target /task/5964 /task/3555587 /task/1102
had_submounts False False False
UAF slab kmalloc-96 kmalloc-64 kmalloc-96
UAF d_flags 0x0 0x81e73ce0 0x0
UAF d_sb 0x0 0x0 0x0
UAF d_lockref.count 0 -14080 -771573072

Consistent findings across all three cores:

- had_submounts is False in every case. detach_mounts() and
namespace_unlock() are not involved in any of these crashes.

- No mounts under /proc/<pid>/... in any mount namespace (checked
on the od0103 core across 49 namespaces, zero proc submounts).

- All three are in the same call path:
release_task -> proc_flush_pid -> d_invalidate ->
shrink_dcache_parent -> shrink_dentry_list -> spin_lock (UAF)

- The UAF'd dentry is in a non-dentry slab in every case (kmalloc-64
or kmalloc-96), confirming the dentry was freed and its page reused
by a different slab cache before shrink_dentry_list tried to lock it.

- Different applications triggered the crash (Rust async runtime,
C++ worker, Java-like worker) -- not application-specific.