CVE-2026-89702

In the Linux kernel, the following vulnerability has been resolved:

nfsd: size fhverify server sockaddr slot by xptlocallen

The nfsdfhverify and nfsdfhverify_err tracepoints declare the

server sockaddr slot sized by xpt_remotelen but fill it from

xptlocal using xptlocallen:

    TPSTRUCT_entry(

            ...

            _sockaddr(server, rqstp->rqxprt->xpt_remotelen)

            ...

    )

    TPfastassign(

            ...

            _assignsockaddr(server, &rqstp->rqxprt->xptlocal,

                              rqstp->rqxprt->xptlocallen);

            ...

    )

When xptlocallen exceeds xptremotelen, _assignsockaddr's memcpy

writes past the reserved ring-buffer slot. In the reverse direction

(xptlocallen < xptremotelen) the slot is oversized and the

unwritten tail leaks prior ring-buffer contents to trace consumers.

The write-past-end case is reachable on NFS/UDP. svcxprtset_remote()

is only called from svctcpaccept() (net/sunrpc/svcsock.c) and from

the RDMA connect path; svccreatesocket() for UDP calls only

svcxprtsetlocal(), so xptremotelen stays 0 for the xprt's

lifetime. Every fh_verify trace for an NFSv2/v3-over-UDP request

then copies 16 or 28 bytes from xpt_local into a zero-byte slot.

The other NFSD tracepoints that record the server address

(NFSDTRACEPROCCALLFIELDS, NFSDTRACEPROCRESFIELDS,

SVCRQSTENDPOINT_FIELDS) already size the server slot by

xptlocallen; nfsdfhverify and nfsdfhverifyerr were the only

exceptions.

Fix by sizing the server slot with xpt_locallen so the declared slot

matches the copy length. The client slot and its assignment already

agree on xpt_remotelen and are left untouched.