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

[VeroFess <coderzeng@gmail.com>]

On Sun, Nov 01, 2026 at 10:51:09AM -0500, Chuck Lever wrote:
> Changes in v6:
> - Verify the current filehandle in SECINFO_NO_NAME(CURRENT_FH) (sashiko).

Hi Chuck,

I tested all three v6 patches on the stated nfsd-testing base,
d9130c9f6535392d423351ffb5521e7689cae6b6. I built and booted
patch 1 alone, patches 1 and 2 together, and the full series in an
x86_64 KASAN guest. The full-series tests also used a second guest for
inter-server COPY and RPC-over-TLS.

I checked the v6 change directly with AUTH_SYS
PUTROOTFH; SECINFO_NO_NAME(CURRENT_FH) on NFSv4.1 and v4.2. With an
xprtsec=tls export over plain TCP, v5 returned OK and v6 returned
NFS4ERR_ACCESS at SECINFO_NO_NAME. With a secure export and a high
source port, v5 returned OK and v6 returned NFS4ERR_PERM at that
operation. PUTROOTFH succeeded in both v6 cases. A mismatched sec=
flavor still returned OK and listed krb5p, as SECINFO_NO_NAME needs
to do. The operation succeeded from a reserved port and over real
TLS 1.3 or mTLS when the export allowed the transport; TLS without
a client certificate was denied by an xprtsec=mtls export.

The original NFSv4.0 Kerberos OPEN stateid reproducer returned
NFS4ERR_WRONGSEC at PUTFH for AUTH_SYS direct and SAVEFH READ/WRITE.
The file was unchanged, and the Kerberos client could still read it.
A second guest tried the same 108 stateid candidates as in the earlier
test and obtained no data. With only patch 1, a protected saved-source
COPY succeeded and changed the destination; CLONE also returned OK. With
patch 2 added, both returned NFS4ERR_ACCESS at their own operations
and left the destination unchanged; authorized COPY and CLONE passed.

With patches 1 and 2, LOOKUPP still crossed from a sec=sys child to a
sec=krb5p parent. The full series returned NFS4ERR_WRONGSEC there
on v4.0, v4.1, and v4.2. SECINFO_NO_NAME(PARENT) remained usable on
v4.1 and v4.2. I also reran the SECINFO name and permission cases,
READDIR with and without rdattr_error or FILEHANDLE, the NFSv2/v3
CREATE cases, and NFSv4 OPEN. Their status and error placement matched
the v5 run.

The other regression tests passed: permitted Btrfs COPY and reflink
CLONE returned matching destination bytes; asynchronous inter-server
COPY completed 4096 bytes between the two guests; protected local
COPY, LINK, and RENAME were rejected; and retained stateids could not
be used after tightening the export's sec= policy. Plaintext, TLS,
and mTLS mount crossings behaved as before on v4.0, v4.1, and v4.2.
A raw v4.0 SECINFO request also succeeded over both TLS and mTLS.

The 259-case source-derived decision test passed under ASan/UBSan.
W=1 fs/nfsd/nfs4proc.o built cleanly with inter-server COPY enabled
and disabled. I saw no KASAN report or kernel Oops. I found no v6
regression in these tests.

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

Thanks,
VeroFess