Re: [PATCH 1/3] NFSD: Prevent post-shutdown use-after-free in unlock_filesystem

Hi Chuck,

I came across a Sashiko AI code review [1] that flagged a remaining
issue in `write_unlock_fs()` — the `nn->nfsd_serv` check is not
sufficient to guarantee that `nfsd_startup_net()` has run and
allocated the state tables.

I was able to trigger it in QEMU with KASAN: creating an NFSD listener
via portlist sets `nn->nfsd_serv`, but without starting any threads,
`nfsd_startup_net()` never runs.  Writing to unlock_filesystem then
calls `nfsd4_cancel_copy_by_sb()` which dereferences the uninitialized
`nfs4_client` hashtable → NULL pointer dereference.

On Tue, Jun 13, 2026 at 03:26:33PM -0400, Chuck Lever wrote:
 > Writing a filesystem path to /proc/fs/nfsd/unlock_filesystem runs
 > nfsd4_cancel_copy_by_sb() before nfsd_mutex is held. This commit moves
 > the async COPY cancel into the nfsd_mutex protected section after
 > checking nn->nfsd_serv to prevent a use-after-free.

This correctly protects against the post-shutdown UAF, but
`nn->nfsd_serv` can be non-NULL while `nfsd_startup_net()` has not
yet been called.  The sequence is:

   echo 2049 > /proc/fs/nfsd/portlist    # sets nn->nfsd_serv
   # threads are still 0 — nfsd_startup_net() never ran
   echo /mnt > /proc/fs/nfsd/unlock_filesystem  # passes nn->nfsd_serv check

`nfsd4_cancel_copy_by_sb()` then iterates `nn->nfs4_client_hashtbl`,
which was allocated by `nfsd_startup_net()` and is still NULL.

[Reproduction]

Create a listener without starting threads, then write to
unlock_filesystem:

   echo 2049 > /proc/fs/nfsd/portlist
   mount -t nfsd nfsd /proc/fs/nfsd
   echo /mnt > /proc/fs/nfsd/unlock_filesystem

[KASAN report — kernel 7.1.0-rc7-next-20260612, CONFIG_KASAN=y]

   Oops: general protection fault, probably for non-canonical address
   0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
   KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]

   RIP: 0010:nfsd4_cancel_copy_by_sb+0x184/0xa70
   Call Trace:
    <TASK>
    write_unlock_fs+0x3ab/0x4f0
    nfsctl_transaction_write+0xfd/0x180
    vfs_write+0x2a5/0x11b0
    ksys_write+0x12f/0x250
    do_syscall_64+0x129/0x880
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

The crash is at offset 0x184 inside `nfsd4_cancel_copy_by_sb()`,
dereferencing a NULL hashtable pointer (`RAX: 0x0000000000000000`).

[1] 
https://sashiko.dev/#/patchset/20260613-unlock-filesystem-uaf-v1-0-462b9bec8c84%40kernel.org
     (Sashiko AI code review — "Null Pointer Dereference", Severity: High)

Thanks,
XIAO