From: "syzbot" <syzbot@kernel.org>
To: syzkaller-bugs@googlegroups.com, Slawomir Stepien <sst@poczta.fm>,
"Anna Schumaker" <anna@kernel.org>,
"Chuck Lever" <cel@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jeff Layton" <jlayton@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>, <linux-nfs@vger.kernel.org>,
<netdev@vger.kernel.org>, "Paolo Abeni" <pabeni@redhat.com>,
"Trond Myklebust" <trondmy@kernel.org>,
"Trond Myklebust" <trond.myklebust@primarydata.com>
Cc: Dai.Ngo@oracle.com, horms@kernel.org,
linux-kernel@vger.kernel.org, neil@brown.name,
okorniev@redhat.com, syzbot@lists.linux.dev, tom@talpey.com
Subject: [PATCH] sunrpc: reject socket already in use in svc_addsock()
Date: Thu, 3 Sep 2026 13:28:54 +0000 (UTC) [thread overview]
Message-ID: <554e50fa-697c-4e57-b5a5-a1c280816436@mail.kernel.org> (raw)
From: Slawomir Stepien <sst@poczta.fm>
When a socket is added to an RPC service via svc_addsock() (for example, by
writing its file descriptor to /proc/fs/nfsd/portlist), svc_setup_socket()
saves the original socket callbacks (such as sk_state_change) into struct
svc_sock and replaces them with RPC-specific callbacks (such as
svc_tcp_state_change). It also attaches the new svc_sock to
sk->sk_user_data.
If the same socket file descriptor is added to an RPC service again,
svc_addsock() invokes svc_setup_socket() a second time on the same socket.
During the second setup, svsk->sk_ostate is assigned the socket's current
sk_state_change callback, which was already replaced with
svc_tcp_state_change. When a state change event subsequently occurs on the
socket (for example, when connect() is called), svc_tcp_state_change()
invokes svsk->sk_ostate, calling itself in an infinite recursion until the
kernel stack overflows and triggers a stack guard page fault:
BUG: TASK stack guard page was hit at ffffc900030b7ff8 (stack is
ffffc900030b8000..ffffc900030c0000)
Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI
...
Call Trace:
<TASK>
svc_tcp_state_change+0x76/0x2e0 net/sunrpc/svcsock.c:917
svc_tcp_state_change+0x76/0x2e0 net/sunrpc/svcsock.c:917
svc_tcp_state_change+0x76/0x2e0 net/sunrpc/svcsock.c:917
...
tcp_done_with_error net/ipv4/tcp_input.c:4877 [inline]
tcp_reset+0x176/0x380 net/ipv4/tcp_input.c:4909
tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:6903 [inline]
tcp_rcv_state_process+0x13bc/0x48a0 net/ipv4/tcp_input.c:7197
tcp_v4_do_rcv+0xafc/0x1530 net/ipv4/tcp_ipv4.c:1876
sk_backlog_rcv include/net/sock.h:1192 [inline]
__release_sock+0x25b/0x390 net/core/sock.c:3260
release_sock+0x190/0x260 net/core/sock.c:3859
inet_wait_for_connect net/ipv4/af_inet.c:616 [inline]
__inet_stream_connect+0x863/0xe00 net/ipv4/af_inet.c:710
inet_stream_connect+0x66/0xa0 net/ipv4/af_inet.c:755
connect_socket net/socket.c:2141 [inline]
__sys_connect_file net/socket.c:2166 [inline]
__sys_connect+0x316/0x450 net/socket.c:2183
...
</TASK>
Fix this by checking if so->sk->sk_user_data is already set in
svc_addsock() before proceeding with svc_setup_socket(). If it is already
non-NULL, return -EBUSY to prevent re-initializing an active socket.
Fixes: fa9251afc33c ("SUNRPC: Call the default socket callbacks instead of open coding")
Assisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+c9834a0c0215e6d8697a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c9834a0c0215e6d8697a
Link: https://syzkaller.appspot.com/ai_job?id=30de91d1-1d14-4676-8c38-a3564f7acf48
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
---
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 50e5e7f5b..e8cc4329f 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -1541,6 +1541,9 @@ int svc_addsock(struct svc_serv *serv, struct net *net, const int fd,
err = -EISCONN;
if (so->state > SS_UNCONNECTED)
goto out;
+ err = -EBUSY;
+ if (so->sk->sk_user_data)
+ goto out;
err = -ENOENT;
if (!try_module_get(THIS_MODULE))
goto out;
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
--
See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
The person who has signed off on the patch is responsible for
addressing comments.
syzbot engineers can be reached at syzkaller@googlegroups.com.
next reply other threads:[~2026-09-03 13:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 13:28 syzbot [this message]
2026-09-03 13:48 ` Chuck Lever
2026-09-03 14:05 ` Slawomir Stepien
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=554e50fa-697c-4e57-b5a5-a1c280816436@mail.kernel.org \
--to=syzbot@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jlayton@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=sst@poczta.fm \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tom@talpey.com \
--cc=trond.myklebust@primarydata.com \
--cc=trondmy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®