DEBIAN-CVE-2026-89702

In the Linux kernel, the following vulnerability has been resolved:  nfsd: size fhverify server sockaddr slot by xptlocallen  The nfsdfhverify and nfsdfhverifyerr tracepoints declare the server sockaddr slot sized by xptremotelen but fill it from xptlocal using xptlocallen:      TPSTRUCTentry(             ...             sockaddr(server, rqstp->rqxprt->xptremotelen)             ...     )     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. svcxprtsetremote() 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 fhverify trace for an NFSv2/v3-over-UDP request then copies 16 or 28 bytes from xptlocal into a zero-byte slot.  The other NFSD tracepoints that record the server address (NFSDTRACEPROCCALLFIELDS, NFSDTRACEPROCRESFIELDS, SVCRQSTENDPOINTFIELDS) already size the server slot by xptlocallen; nfsdfhverify and nfsdfhverifyerr were the only exceptions.  Fix by sizing the server slot with xptlocallen so the declared slot matches the copy length. The client slot and its assignment already agree on xptremotelen and are left untouched.