CVE-2026-89702
moderateTrace ring-buffer overflow in Linux kernel nfsd fh_verify tracepoints via NFS-over-UDP
The Linux kernel's nfsd_fh_verify and nfsd_fh_verify_err tracepoints size their server sockaddr slot using xpt_remotelen but fill it from xpt_local using xpt_locallen, so when xpt_locallen exceeds xpt_remotelen the __assign_sockaddr memcpy writes past the reserved trace ring-buffer slot; the reverse mismatch leaks stale ring-buffer contents to trace readers. The overflow is reachable over NFS/UDP because svc_xprt_set_remote() is only called on the TCP-accept and RDMA-connect paths, leaving xpt_remotelen at 0 for UDP transports, so every fh_verify trace for an NFSv2/v3-over-UDP request copies 16 or 28 bytes from xpt_local into a zero-byte slot. An attacker who can send NFS requests to a UDP-listening NFS server (while these tracepoints are enabled) causes out-of-bounds writes into the kernel trace ring buffer, with the smaller-slot direction additionally disclosing prior ring-buffer memory to trace consumers. Affected systems are Linux kernels running the NFS server (nfsd) with the fh_verify tracepoints active, particularly those serving NFSv2/v3 over UDP; the issue is rated CVSS 3.1 9.8 (critical). No public PoC is known, the flaw is not in CISA's KEV catalog, and no exploitation in the wild has been reported.
What to do: Update to a kernel that contains the fix (the server sockaddr slot in both tracepoints is sized by xpt_locallen so slot and copy length match). Until patched, disable NFS over UDP on nfsd listeners (prefer NFSv4.2 over TCP) and ensure the nfsd fh_verify tracepoints / tracefs tracing are not enabled on production NFS servers. Check existing NFS exports for 'udp' mount options and audit whether ftrace/tracefs has nfsd tracepoints active on any exposed host.
| Linux kernel (nfsd tracepoints nfsd_fh_verify / nfsd_fh_verify_err) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.