All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+96046021045ffe6d7709@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: Re: [syzbot] [rds?] general protection fault in rds_tcp_accept_one
Date: Mon, 09 Feb 2026 23:05:12 -0800	[thread overview]
Message-ID: <698ad8a8.050a0220.1ad825.0060.GAE@google.com> (raw)
In-Reply-To: <698a0023.050a0220.3b3015.0078.GAE@google.com>

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: Re: [syzbot] [rds?] general protection fault in rds_tcp_accept_one
Author: allison.henderson@oracle.com

#syz test: git@github.com:allisonhenderson/rds_work.git rds_tcp_bug_fixes_v14

commit 86b003db7ed7f474c3f462643c2912ffdeb2f876
Author: Allison Henderson <achender@kernel.org>
Date:   Mon Feb 9 18:20:42 2026 -0700

    net/rds: Fix NULL pointer dereference in rds_tcp_accept_one
    
    Hold a local reference to new_sock->sk before installing callbacks
    in rds_tcp_accept_one. After rds_tcp_set_callbacks() or
    rds_tcp_reset_callbacks(), tc->t_sock is set to new_sock which
    may race with the shutdown path.  A concurrent
    rds_tcp_conn_path_shutdown() may call sock_release(), which sets
    new_sock->sk = NULL and frees sk.
    
    Subsequent accesses to new_sock->sk->sk_state dereference NULL,
    causing the null dereference. So a local sock reference with
    sock_hold() before installing callbacks will prevent the race.
    
    Fixes: 826c1004d4ae ("net/rds: rds_tcp_conn_path_shutdown must not discard messages")
    Reported-by: syzbot+96046021045ffe6d7709@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=96046021045ffe6d7709
    Signed-off-by: Allison Henderson <achender@kernel.org>

diff --git a/net/rds/tcp_listen.c b/net/rds/tcp_listen.c
index 6fb5c928b8fd..cdc86473a1ba 100644
--- a/net/rds/tcp_listen.c
+++ b/net/rds/tcp_listen.c
@@ -177,6 +177,7 @@ int rds_tcp_accept_one(struct rds_tcp_net *rtn)
 	struct rds_tcp_connection *rs_tcp = NULL;
 	int conn_state;
 	struct rds_conn_path *cp;
+	struct sock *sk;
 	struct in6_addr *my_addr, *peer_addr;
 #if !IS_ENABLED(CONFIG_IPV6)
 	struct in6_addr saddr, daddr;
@@ -298,6 +299,14 @@ int rds_tcp_accept_one(struct rds_tcp_net *rtn)
 		rds_conn_path_drop(cp, 0);
 		goto rst_nsk;
 	}
+	/* Hold a local reference to sk before setting callbacks. Once callbacks
+	 * are set, it is possible for a concurrent rds_tcp_conn_path_shutdown
+	 * call to release the new_sock->sk and set it to NULL.  So we use
+	 * a local sk here to avoid racing with callbacks
+	 */
+	sk = new_sock->sk;
+	sock_hold(sk);
+
 	if (rs_tcp->t_sock) {
 		/* Duelling SYN has been handled in rds_tcp_accept_one() */
 		rds_tcp_reset_callbacks(new_sock, cp);
@@ -316,13 +325,15 @@ int rds_tcp_accept_one(struct rds_tcp_net *rtn)
 	 * knowing that "rds_tcp_conn_path_shutdown" will
 	 * dequeue pending messages.
 	 */
-	if (new_sock->sk->sk_state == TCP_CLOSE_WAIT ||
-	    new_sock->sk->sk_state == TCP_LAST_ACK ||
-	    new_sock->sk->sk_state == TCP_CLOSE)
+	if (READ_ONCE(sk->sk_state) == TCP_CLOSE_WAIT ||
+	    READ_ONCE(sk->sk_state) == TCP_LAST_ACK ||
+	    READ_ONCE(sk->sk_state) == TCP_CLOSE)
 		rds_conn_path_drop(cp, 0);
 	else
 		queue_delayed_work(cp->cp_wq, &cp->cp_recv_w, 0);
 
+	sock_put(sk);
+
 	new_sock = NULL;
 	ret = 0;
 	if (conn->c_npaths == 0)

  parent reply	other threads:[~2026-02-10  7:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-09 15:41 [syzbot] [rds?] general protection fault in rds_tcp_accept_one syzbot
2026-02-10  2:15 ` Forwarded: " syzbot
2026-02-10  7:05 ` syzbot [this message]
2026-02-10  7:31 ` syzbot

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=698ad8a8.050a0220.1ad825.0060.GAE@google.com \
    --to=syzbot+96046021045ffe6d7709@syzkaller.appspotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /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.