Re: [PATCH v5 0/3] NFSD: Enforce export security after a deferred PUTFH check

[VeroFess <coderzeng@gmail.com>]

On Sat, Oct 31, 2026 at 05:27:34AM +0800, Chuck Lever wrote:
> The series as posted has not been run against the reproducer yet.

Thanks for splitting the series. I tested it incrementally in an
x86_64 KASAN guest on d9130c9f6535: patch 1 alone, then patches 1 and
2, then the full series. I'm happy to test further revisions.

With only patch 1 applied, the NFSv4.0 reproducer returned
NFS4ERR_WRONGSEC at PUTFH for AUTH_SYS PUTFH; SAVEFH; READ and
PUTFH; SAVEFH; WRITE. The file was unchanged and the Kerberos client
could still read it, so patch 1 by itself stops the reported sequence.

Adding patch 2: with patch 1 only, an AUTH_SYS local COPY of a krb5p
source still completed and changed the destination; with patch 2 the
saved-source check made COPY and CLONE return NFS4ERR_ACCESS and leave
the destination unchanged. A permitted AUTH_SYS local COPY still
succeeded.

Adding patch 3: LOOKUPP into a krb5p parent, which succeeded before
patch 3, returned WRONGSEC, while SECINFO_NO_NAME(PARENT) still
succeeded. READDIR with rdattr_error reported WRONGSEC for the strict
child, and the NFSv2/v3 CREATE cases returned ACCESS. Over plaintext
TCP, SECINFO into an xprtsec=tls child returned NFS4ERR_ACCESS while
LOOKUP returned WRONGSEC.

On the full series I reran the earlier regression suite: Btrfs local
COPY and reflink CLONE succeeded with matching destination bytes, and
asynchronous inter-server COPY completed 4096 bytes between two guests.

I also rebuilt the full series with CONFIG_TLS=y for an RPC-over-TLS
run. On NFSv4.0, v4.1, and v4.2, a plaintext client could read the
parent export but could not enter its xprtsec=tls child; a TLS client
could read the child. For an xprtsec=mtls child, TLS without a client
certificate was denied, and mTLS with a trusted certificate succeeded
on all three versions. A raw NFSv4.0 PUTROOTFH; SECINFO request
returned NFS4_OK over both TLS and mTLS.

The W=1 fs/nfsd/nfs4proc.o build and the 259-case ASan/UBSan check
passed, with no KASAN reports.

Tested-by: VeroFess <coderzeng@gmail.com>

Thanks,
VeroFess