Re: [PATCH 0/6] SUNRPC: Address remaining cache_check_rcu() UAF in cache content files

Hi Erkun -

On Fri, May 8, 2026, at 9:00 AM, yangerkun wrote:

在 2026/5/8 16:16, yangerkun 写道:

quoted

在 2026/5/8 11:08, yangerkun 写道:
After reviewing these two commits:

e7fcf179b82d NFSD: Hold net reference for the lifetime of /proc/fs/nfs/ 
exports fd
48db892356d6 NFSD: Defer sub-object cleanup in export put callbacks

I believe that the issue described in commit e7fcf179b82d might be the
root cause of the null pointer dereferences mentioned in [1].

That's where I landed too. e7fcf179b82d closed the specific
oops Misbah hit on /proc/fs/nfs/exports. The matching patch
in this series is 5/6 ("SUNRPC: Hold cd->net for the lifetime
of cache files"), which extends the same get_net()/put_net()
guard to the sunrpc cache files at

 /proc/net/rpc/<cache>/{content,channel,flush} .

Those open helpers had the same hole; sosreport just hit the
nfsd-specific file first because it reads /proc/fs/nfsd/exports.

Patch 5/6's changelog pins down the deref site you asked
about: cache_check_rcu() faults reading h->flags off a
garbage cache_head returned by __cache_seq_start() walking a
cd->hash_table that cache_destroy_net() already freed. Not a
dentry deref. The dentry-teardown path is a separate failure
mode that 48db892356d6 closed for the export and expkey caches.

quoted

To prevent the
issue described in commit 69d803c40ede, should we consider reverting
commit 48db892356d6 first?

Not for this series. Patches 3/6 and 4/6 don't add any new
path_put deferral; their commit messages call them out as
consistency changes, not bug fixes. ip_map holds only an
auth_domain reference and unix_gid holds only a group_info,
so neither cache reaches mntput from the deferred release.
The exportfs-r-then-umount sequence isn't touched by this
series.

The svc_export and svc_expkey path_put deferral lives in
48db892356d6, which is already in v7.0. If the umount window
from 69d803c40ede is still reachable through that commit,
that's a regression in 48db892356d6 and worth a separate
thread.

Locally, I wrote a stable regression test case. I also reverted to 
commit 9189d23b835cec646ba5010db35d1557a77c5857 (which is before commits 
2862eee078a4 "SUNRPC: make sure cache entry active before cache_show" 
and be8f982c369c "nfsd: make sure exp active before svc_export_show"). 
Even then, a panic can still be triggered without any actual export path...

That fits 5/6's failure mode. Without an export no svc_export
or svc_expkey entry is populated, but rpc.mountd reads
auth.unix.ip/content and auth.unix.gid/content directly,
and on a pre-5/6 tree the open helpers in cache.c hold no
reference on cd->net. cache_destroy_net() at namespace exit
then races a reader still inside cache_seq_start_rcu(), and
the reader walks a freed cd->hash_table.                                                                                                                               

Could you share the reproducer and the panic stack trace?
If the fault is in cache_check_rcu() through one of the
sunrpc cache files, that confirms 5/6 is the right fix, and
I'll happily carry your Tested-by on it.


-- 
Chuck Lever