From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-89702: nfsd: size fh_verify server sockaddr slot by xpt_locallen
Date: Fri, 11 Sep 2026 21:46:31 +0200 [thread overview]
Message-ID: <2026091156-CVE-2026-89702-ff5b@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
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.
The Linux kernel CVE team has assigned CVE-2026-89702 to this issue.
Affected and fixed versions
===========================
Issue introduced in 6.0 with commit 051382885552e12541cc0ebf82092be374a9ed2a and fixed in 6.12.109 with commit 95d064f9828a20ccca5ae90a17be3e2076f25272
Issue introduced in 6.0 with commit 051382885552e12541cc0ebf82092be374a9ed2a and fixed in 6.18.50 with commit 7ff8d6363cffff45654ea85e319f7c0c54226012
Issue introduced in 6.0 with commit 051382885552e12541cc0ebf82092be374a9ed2a and fixed in 7.2.4 with commit 719a10e3f5f868c3c4ac3cf3648c5775d12034bd
Issue introduced in 6.0 with commit 051382885552e12541cc0ebf82092be374a9ed2a and fixed in 7.3-rc1 with commit 71d068490098b1d23c63b2345e40675d3a1ca763
Issue introduced in 5.15.154 with commit dcbebc86850324fbe0a993ce352f0539cd98038a
Issue introduced in 5.15.154 with commit 62980365d6e894234b29f44fb2bfad4f7f8bb824
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-89702
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
fs/nfsd/trace.h
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/95d064f9828a20ccca5ae90a17be3e2076f25272
https://git.kernel.org/stable/c/7ff8d6363cffff45654ea85e319f7c0c54226012
https://git.kernel.org/stable/c/719a10e3f5f868c3c4ac3cf3648c5775d12034bd
https://git.kernel.org/stable/c/71d068490098b1d23c63b2345e40675d3a1ca763
reply other threads:[~2026-09-11 20:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026091156-CVE-2026-89702-ff5b@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.