svc_rpc_gss_validate() copies the input message into a stack buffer
without ensuring that the buffer is large enough.  Sure enough,
oa_length may be up to 400 bytes, much larger than the provided space.
This enables an unauthenticated user to trigger an overflow and obtain
remote code execution.

Add a runtime check which verifies that the copy won't overflow.

Approved by:	so
Security:	FreeBSD-SA-26:08.rpcsec_gss
Security:	CVE-2026-4747
Reported by:	Nicholas Carlini <npc@anthropic.com>
Reviewed by:	rmacklem
Fixes:		a9148abd9da5d

There were two debug printf()s that were left in the
code while debugging the handling of callbacks over
a NFSv4.1/4.2 backchannel was being done.

This patch removes them, since they are no longer
of benefit and cause "noise".

Requested by:	wollman
MFC after:	2 weeks

so_state modifications must be synchronized by the socket lock.  For the
listening socket this probably doesn't matter but for the child socket I
think it's possible that this unlocked update clobbers a state
transition if the nascent connection is being disconnected for some
reason.

Also fix the line which potentially clears SS_NBIO in the listening
socket.

It is unclear whether this code is used at all.

Reviewed by:	glebius
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D55247

The type of xdrproc_t is clearly defined in the comments as a function
with two arguments, an XDR * and a void * (sometimes spelled caddr_t).
It was initialy defined as:

	typedef bool_t (*xdrproc_t)();

At some point people started giving it a non-empty argument list.
Unfortunatly, there has been widespread disagreement about how arguments
are passed.  There seems to have been a widespread view that it should
be allowed to pass three argument function pointer to xdrproc_t.  Most
notable is xdr_string which takes a maximum length parameter. This lead
to all sorts of prototypes (all of which have been present in the
FreeBSD source tree):

FreeBSD userspace (nominally from tirpc, but seemingly local):
	typedef bool_t (*xdrproc_t)(XDR *, ...);
FreeBSD kernel, glibc:
	typedef bool_t (*xdrproc_t)(XDR *, void *, ...);
rcp/xdr.h with _KERNEL defined (not used?):
	typedef bool_t (*xdrproc_t)(XDR *, void *, u_int);
gssrpc (in krb5) and Linux kernel:
	typedef bool_t (*xdrproc_t)(XDR *, void *);

For two argument functions on current ABIs, these all equivalent as
these arguments are passed in registers regardless of decleration and
definition, but we end up with two problems:

   - xdr_free((xdrproc_t)xdr_string, ...) calls xdr_string with no third
     argument and (at least on FreeBSD) may fail to free memory if the
     string is shorter than the value lying around in the third argument
     register.  There are no instance of this in tree, but I found some
     with Debian code search, in particular in OpenAFS.

   - Under CheriABI, variadic arguments are passed in a separate,
     bounded array so theses prototypes aren't equilvalent to the
     non-variadic calling convention of the functions.

The reality is that that xdr_string should not be cast to xdrproc_t and
xdr_wrapstring should be used instead so we do not need to support this
case.  Instances of the former behavior are now extremely rare.

With this change we bring FreeBSD in line with gssrpc and the Linux
Kernel.  Warnings about casts should now be correct and should be fixed.

Bump __FreeBSD_version as some software required adaptation if it is
declaring functions to cast to xdrproc_t.  Update OpenZFS's workaround
of this historic mess accordingly.

Effort:		CHERI upstreaming
Sponsored by:	Innovate UK

Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D54824

This fixes the build on CHERI architectures where the compiler warns
about a direct cast between uint64_t and const void * inside of
__DECONST.  However, GCC would also complain about this on 32-bit
kernels due to uint64_t not being the same size as a pointer.  Also,
a direct cast to uintptr_t to right-size the cookie value is more
direct than using __DECONST given that there is no "const" pointer
involved in the expression.

Reviewed by:	brooks, glebius
Obtained from:	CheriBSD
Sponsored by:	AFRL, DARPA
Differential Revision:	https://reviews.freebsd.org/D54797

Remove the printf() stances added in commit d4cc791f3b2e ("sys/rpc: UNIX
auth: Fix OOB reads on too short message").

Even if it can be helpful to know why an authentication message is
rejected, printing explanatory messages on each request attempt is
a remote log filler that could be triggered by accident, and the generic
RPC code generally does not do that.  These printf() calls should be
restored only after some limiting or configuration mechanism is devised.

MFC with:       d4cc791f3b2e ("sys/rpc: UNIX auth: Fix OOB reads on too short message")
Sponsored by:   The FreeBSD Foundation

MFC after:      2 days
Sponsored by:   The FreeBSD Foundation

xdr_authunix_parms() does not allocate any auxiliary memory, so we can
simply support XDR_FREE by just returning TRUE.

Although there are currently no callers passing XDR_FREE, this makes us
immune to such a change in a way that doesn't cost more but is more
constructive than a mere KASSERT().

Suggested by:   rmacklem
MFC after:      2 days
Sponsored by:   The FreeBSD Foundation

In the inline version (_svcauth_unix()), fix multiple possible OOB reads
when the credentials part of a request is too short to contain mandatory
fields or with respect to the hostname length or number of groups it
advertises.  The previously existing check was arriving too late and
relied on possibly wrong data coming from earlier OOB reads.

While here, use 'uint32_t' as the length/size type, as it is more than
enough and removes the need for conversions, explicit or implicit.
While here, factor out setting 'stat' to AUTH_BADCRED and then jumping
to 'done' on error, through the new 'badcred' label.  While here,
through comments, refer to what the non-inline version is doing
(xdr_authunix_parms() in 'authunix_prot.c') and the reasons.

Reviewed by:    rmacklem
Fixes:          dfdcada31e79 ("Add the new kernel-mode NFS Lock Manager.")
MFC after:      2 days
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D52964

Remove local defines from 'svc_auth_unix.c' and use the new limit
macros instead.

Reviewed by:    rmacklem
MFC after:      2 days
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D52963