CVE-2026-89702
Critical · 9.8CVSS
9.8
EPSS
0.5%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's NFS server tracing code can let an unauthenticated network user corrupt memory or leak internal data simply by sending normal file requests over UDP.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Mismatched sockaddr slot sizing in nfsd_fh_verify tracepoints causes memcpy to write past the ring-buffer allocation when xpt_locallen exceeds xpt_remotelen on NFS/UDP, or to leave uninitialized data in the slot when the reverse occurs.
Why it matters to the business
Kernel memory corruption or information disclosure can occur during routine NFS/UDP operations, potentially leading to system instability or exposure of prior kernel data with no required authentication.
How an attack unfolds
An attacker sends NFSv2/v3 requests over UDP to a vulnerable nfsd instance; each fh_verify trace event triggers an out-of-bounds write into the trace ring buffer because the slot was sized by xpt_remotelen while data is copied using xpt_locallen.
How to fix it
Apply the upstream fix that changes the server sockaddr slot declaration and assignment in nfsd_fh_verify and nfsd_fh_verify_err tracepoints to use xpt_locallen; rebuild and deploy the corrected kernel.
How to confirm the fix worked
Confirm the corrected tracepoint macros size the server slot by xpt_locallen and that xpt_remotelen is no longer used for that field; inspect ring-buffer contents after UDP NFS traffic for correct sizing and absence of overruns.
Typical attack path
- Establish UDP connectivity to the NFS server
- Issue NFSv2 or NFSv3 file-handle verification requests
- Trigger repeated fh_verify tracepoints
- Cause either memory corruption or leakage of prior ring-buffer contents
How to detect it
Review kernel trace logs and ring-buffer dumps around periods of UDP NFS activity for evidence of oversized or truncated sockaddr entries; correlate with nfsd_fh_verify tracepoint firings.
What your security team should do
- Patch nfsd tracepoint code immediately given the CVSS 9.8 score
- Disable NFS/UDP listeners where feasible until patches are applied
- Monitor kernel trace and audit logs for anomalous ring-buffer or sockaddr activity
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|