Description

In the Linux kernel, the following vulnerability has been resolved: nfsd: size fh_verify server sockaddr slot by xpt_locallen The nfsd_fh_verify and nfsd_fh_verify_err tracepoints declare the server sockaddr slot sized by xpt_remotelen but fill it from xpt_local using xpt_locallen: TP_STRUCT__entry( ... __sockaddr(server, rqstp->rq_xprt->xpt_remotelen) ... ) TP_fast_assign( ... __assign_sockaddr(server, &rqstp->rq_xprt->xpt_local, rqstp->rq_xprt->xpt_locallen); ... ) When xpt_locallen exceeds xpt_remotelen, __assign_sockaddr's memcpy writes past the reserved ring-buffer slot. In the reverse direction (xpt_locallen < xpt_remotelen) 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. svc_xprt_set_remote() is only called from svc_tcp_accept() (net/sunrpc/svcsock.c) and from the RDMA connect path; svc_create_socket() for UDP calls only svc_xprt_set_local(), so xpt_remotelen 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 (NFSD_TRACE_PROC_CALL_FIELDS, NFSD_TRACE_PROC_RES_FIELDS, SVC_RQST_ENDPOINT_FIELDS) already size the server slot by xpt_locallen; nfsd_fh_verify and nfsd_fh_verify_err 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:57.413Z",
  "pubdate": "2026-09-11T20:19:57.413Z",
  "executiveSummary": "A memory safety vulnerability exists in the Linux kernel nfsd subsystem related to tracepoint data structures. The flaw is categorized as a heap-based buffer overflow and potential information disclosure.\nThe issue specifically affects the nfsd_fh_verify and nfsd_fh_verify_err tracepoints, which incorrectly size a buffer intended to store local socket addresses.\nIn scenarios where the local address length (xpt_locallen) exceeds the reserved remote address length (xpt_remotelen), the kernel performs an out-of-bounds write to the trace buffer.\nConversely, if xpt_locallen is smaller than the reserved space, the kernel may leak uninitialized ring-buffer memory to userspace trace consumers.\nThis vulnerability is particularly reachable in NFSv2/v3-over-UDP configurations, where the remote address length is often zero, causing every file handle verification trace to trigger an overflow.\nSuccessful exploitation allows for memory corruption within the kernel's tracing ring buffer. While primarily impacting system stability, information disclosure of kernel memory contents could assist in bypassing KASLR or other security controls.",
  "technicalDetails": "The root cause of this vulnerability is an inconsistent memory allocation and assignment logic within the nfsd_fh_verify and nfsd_fh_verify_err tracepoints. These tracepoints define the 'server' sockaddr slot size using the transport's remote address length (xpt_remotelen), but the subsequent data assignment (via __assign_sockaddr) copies data from the local address (xpt_local) using the local address length (xpt_locallen).\nIn the Linux kernel's sunrpc infrastructure, xpt_remotelen and xpt_locallen represent the byte-length of the remote and local sockaddr structures, respectively. For NFS/UDP implementations, the remote address length is typically initialized to zero because the transport is connectionless. When nfsd_fh_verify triggers a trace, the TP_STRUCT__entry reserves zero bytes for the server sockaddr. However, the TP_fast_assign block then attempts to copy 16 or 28 bytes (the size of an IPv4 or IPv6 address) into that zero-byte slot using memcpy.\nThe exploitation flow proceeds as follows: 1) An attacker initiates an NFS request over UDP to a vulnerable nfsd instance. 2) The request causes the kernel to execute an fh_verify operation. 3) The kernel reaches the vulnerable tracepoint, which triggers a heap-based buffer overflow in the ftrace/ring-buffer memory space due to the mismatch between the declared slot size and the actual data being copied. 4) If the buffer is undersized, memory adjacent to the trace buffer is corrupted. If the buffer is oversized, the remaining bytes in the trace entry remain uninitialized and contain stale kernel memory contents.\nThis flaw effectively results in an out-of-bounds write of arbitrary socket address data into the kernel's tracing subsystem. Because the tracing ring buffer is shared, the impact is two-fold: memory corruption of trace metadata and the potential for kernel heap information disclosure. The vulnerability is persistent across NFSv2/v3 UDP-enabled environments where local addresses are tracked via the transport structures. No special user privileges are required to trigger the overflow if the attacker has network access to the NFS mount point, making this a reachable attack surface for any network-connected client."
}