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

["Chuck Lever" <cel@kernel.org>]

Hi Erkun -

On Fri, May 8, 2026, at 9:00 AM, yangerkun wrote:
> 在 2026/5/8 16:16, yangerkun 写道:
>> 
>> 
>> 在 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.


>> 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