CVE-2026-89702: nfsd: size fh_verify server sockaddr slot by xpt_locallen
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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the out-of-bounds write condition?
NFSD deployments serving NFSv2 or NFSv3 requests over UDP are exposed. For UDP transports, xpt_remotelen remains zero while the local address length is 16 or 28 bytes, so an fh_verify trace copies the local address into a zero-byte ring-buffer slot.
What must occur for the vulnerable copy to be reached?
An NFSv2 or NFSv3 request must be handled over UDP and produce an fh_verify trace. The issue is in the tracepoint assignment for the server address, not in the normal transport address setup itself.
Is this only a memory-corruption issue?
No. When the local address length is greater than the remote address length, the tracepoint write overruns its reserved ring-buffer slot. In the opposite size mismatch, the slot is oversized and its unwritten tail can expose prior ring-buffer contents to trace consumers.