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

[VeroFess <coderzeng@gmail.com>]

Chuck,

I finished testing the posted v7 series on an x86-64 KASAN guest with
NFSv2/v3/v4, Btrfs, inter-server COPY, and kernel TLS enabled. The
five patches applied in order to d9130c9f6535 and the bzImage built.
The tested image has SHA-256
99c8dad605aba384985097b6fad00f26db19ea8074b5b862d145b928e9b4b975.

The original NFSv4.0 AUTH_SYS SAVEFH reproducer returned WRONGSEC for
READ and WRITE against the krb5p export. The destination was unchanged,
and none of 108 candidate stateids returned the protected data. The
v4.2 saved-source COPY and CLONE tests returned ACCESS on the denied
source and left the destination unchanged. Authorized local COPY and
CLONE, inter-server COPY with COPY_NOTIFY and OFFLOAD_STATUS, and the
asynchronous negative cases behaved as expected.

I also reran the v6 regression matrix on v7: SAVEFH and RESTOREFH
boundaries, error ordering, LOOKUP and LOOKUPP, OPEN by name and by
filehandle, SECINFO and SECINFO_NO_NAME, READDIR with rdattr_error,
LINK and RENAME, NFSv2/v3 CREATE, v4 OPEN UNCHECKED, and export policy
changes from sec=sys to krb5p. The GSS cases covered krb5, krb5i,
and krb5p on v4.0, v4.1, and v4.2. These checks passed.

For patches 4 and 5, I ran the GSS cases against the changed SECINFO
and PUTFH paths. PUTFH deferred the flavor error where required;
SECINFO returned the available flavors; a following operation did not
use a stale current filehandle. I repeated the root and child-export
checks over plaintext, TLS, and mTLS on v4.0, v4.1, and v4.2, and ran
krb5p over TLS 1.3 on v4.1 and v4.2. The permitted requests succeeded
and the denied requests returned the expected errors. No KASAN report
or kernel oops appeared in the guest log.

The W=1 NFSD object builds passed with NFSD_V4_2_INTER_SSC enabled and
disabled. The need_wrongsec_check() decision harness passed 259/259
cases.

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

VeroFess