Skip to contentSkip to conversation

net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()

PATCH Superseded Jiayuan Chen 3 participants 4 messages Mar 10

Subsystems (5)
Networking Network drivers InfiniBand s390 +1 more subsystems

v3 of 5 Superseded Latest is v5 →

lore
Share & tools
lore

Jiayuan Chen

author
#0 lore raw

PATCH v3 1/1 net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()

From: Jiayuan Chen <[email protected]>

Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].

smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release().

This leads to two issues:

1) NULL pointer dereference: sk_user_data is NULL when accessed.
2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.

The race window looks like this:

CPU A (softirq) CPU B (process ctx)

tcp_v4_rcv()

    TCP_NEW_SYN_RECV:
    sk = req->rsk_listener
    sock_hold(sk)
    /* No lock on listener */
                               smc_close_active():
                                 write_lock_bh(cb_lock)
                                 sk_user_data = NULL
                                 write_unlock_bh(cb_lock)
                                 ...
                                 smc_clcsock_release()
                                 sock_put(smc->sk) x2
                                   -> smc_sock freed!
    tcp_check_req()
      smc_tcp_syn_recv_sock():
        smc = user_data(sk)
          -> NULL or dangling
        smc->queued_smc_hs
          -> crash!

Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed.

Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight.

- Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock().
- Use rcu_read_lock() to protect reading sk_user_data.
- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.

Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected.

Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9

Fixes 8270d9c21041 ("net/smc: Limit backlog connections")
Reported-by [email protected]
Closes https://lore.kernel.org/all/[email protected]/T/ open here
Suggested-by Eric Dumazet <[email protected]>
Cc Jiayuan Chen <[email protected]>
Signed-off-by Jiayuan Chen <[email protected]>

---
v2 -> v3:
- Use rcu_dereference_sk_user_data() for reading and rcu_assign_sk_user_data() for writing sk_user_data to
prevent load/store tearing, as pointed out by Eric Dumazet.
v2: https://lore.kernel.org/netdev/[email protected]/

v1 -> v2:
- Use rcu_read_lock() + refcount_inc_not_zero() instead of read_lock_bh(sk_callback_lock) + sock_hold(), since this
is the TCP handshake hot path and read_lock_bh is too
expensive under SYN flood.
- Set SOCK_RCU_FREE on SMC listen socket to ensure
RCU-deferred freeing.
v1: https://lore.kernel.org/netdev/[email protected]/

---
 net/smc/af_smc.c    | 19 ++++++++++++++-----
 net/smc/smc.h       |  3 +--
 net/smc/smc_close.c |  2 +-
 3 files changed, 16 insertions(+), 8 deletions(-)
net/smc/af_smc.c +14 -5
index d0119afcc6a1..078927ba068a 100644
@@ -131,7 +131,13 @@ static struct sock *smc_tcp_syn_recv_sock(const struct sock *sk,
 	struct smc_sock *smc;
 	struct sock *child;
 
+	rcu_read_lock();
 	smc = smc_clcsock_user_data(sk);
+	if (!smc || !refcount_inc_not_zero(&smc->sk.sk_refcnt)) {
+		rcu_read_unlock();
+		return NULL;
+	}
+	rcu_read_unlock();
 
 	if (READ_ONCE(sk->sk_ack_backlog) + atomic_read(&smc->queued_smc_hs) >
 				sk->sk_max_ack_backlog)

@@ -153,11 +159,13 @@ static struct sock *smc_tcp_syn_recv_sock(const struct sock *sk,
 		if (inet_csk(child)->icsk_af_ops == inet_csk(sk)->icsk_af_ops)
 			inet_csk(child)->icsk_af_ops = smc->ori_af_ops;
 	}
+	sock_put(&smc->sk);
 	return child;
 
 drop:
 	dst_release(dst);
 	tcp_listendrop(sk);
+	sock_put(&smc->sk);
 	return NULL;
 }
 

@@ -254,7 +262,7 @@ static void smc_fback_restore_callbacks(struct smc_sock *smc)
 	struct sock *clcsk = smc->clcsock->sk;
 
 	write_lock_bh(&clcsk->sk_callback_lock);
-	clcsk->sk_user_data = NULL;
+	rcu_assign_sk_user_data(clcsk, NULL);
 
 	smc_clcsock_restore_cb(&clcsk->sk_state_change, &smc->clcsk_state_change);
 	smc_clcsock_restore_cb(&clcsk->sk_data_ready, &smc->clcsk_data_ready);

@@ -902,7 +910,7 @@ static void smc_fback_replace_callbacks(struct smc_sock *smc)
 	struct sock *clcsk = smc->clcsock->sk;
 
 	write_lock_bh(&clcsk->sk_callback_lock);
-	clcsk->sk_user_data = (void *)((uintptr_t)smc | SK_USER_DATA_NOCOPY);
+	__rcu_assign_sk_user_data_with_flags(clcsk, smc, SK_USER_DATA_NOCOPY);
 
 	smc_clcsock_replace_cb(&clcsk->sk_state_change, smc_fback_state_change,
 			       &smc->clcsk_state_change);

@@ -2665,8 +2673,8 @@ int smc_listen(struct socket *sock, int backlog)
 	 * smc-specific sk_data_ready function
 	 */
 	write_lock_bh(&smc->clcsock->sk->sk_callback_lock);
-	smc->clcsock->sk->sk_user_data =
-		(void *)((uintptr_t)smc | SK_USER_DATA_NOCOPY);
+	__rcu_assign_sk_user_data_with_flags(smc->clcsock->sk, smc,
+					     SK_USER_DATA_NOCOPY);
 	smc_clcsock_replace_cb(&smc->clcsock->sk->sk_data_ready,
 			       smc_clcsock_data_ready, &smc->clcsk_data_ready);
 	write_unlock_bh(&smc->clcsock->sk->sk_callback_lock);

@@ -2687,10 +2695,11 @@ int smc_listen(struct socket *sock, int backlog)
 		write_lock_bh(&smc->clcsock->sk->sk_callback_lock);
 		smc_clcsock_restore_cb(&smc->clcsock->sk->sk_data_ready,
 				       &smc->clcsk_data_ready);
-		smc->clcsock->sk->sk_user_data = NULL;
+		rcu_assign_sk_user_data(smc->clcsock->sk, NULL);
 		write_unlock_bh(&smc->clcsock->sk->sk_callback_lock);
 		goto out;
 	}
+	sock_set_flag(sk, SOCK_RCU_FREE);
 	sk->sk_max_ack_backlog = backlog;
 	sk->sk_ack_backlog = 0;
 	sk->sk_state = SMC_LISTEN;
net/smc/smc.h +1 -2
index 9e6af72784ba..8b3eabcdb542 100644
@@ -342,8 +342,7 @@ static inline void smc_init_saved_callbacks(struct smc_sock *smc)
 
 static inline struct smc_sock *smc_clcsock_user_data(const struct sock *clcsk)
 {
-	return (struct smc_sock *)
-	       ((uintptr_t)clcsk->sk_user_data & ~SK_USER_DATA_NOCOPY);
+	return (struct smc_sock *)rcu_dereference_sk_user_data(clcsk);
 }
 
 /* save target_cb in saved_cb, and replace target_cb with new_cb */
net/smc/smc_close.c +1 -1
index 10219f55aad1..bb0313ef5f7c 100644
@@ -218,7 +218,7 @@ int smc_close_active(struct smc_sock *smc)
 			write_lock_bh(&smc->clcsock->sk->sk_callback_lock);
 			smc_clcsock_restore_cb(&smc->clcsock->sk->sk_data_ready,
 					       &smc->clcsk_data_ready);
-			smc->clcsock->sk->sk_user_data = NULL;
+			rcu_assign_sk_user_data(smc->clcsock->sk, NULL);
 			write_unlock_bh(&smc->clcsock->sk->sk_callback_lock);
 			rc = kernel_sock_shutdown(smc->clcsock, SHUT_RDWR);
 		}
Signature · 1 line
2.43.0
#1 lore raw
Quoted 53 lines · Jiayuan Chen

From: Jiayuan Chen <[email protected]>

Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].

smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release().

This leads to two issues:

1) NULL pointer dereference: sk_user_data is NULL when accessed.
2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.

The race window looks like this:

CPU A (softirq) CPU B (process ctx)

tcp_v4_rcv()

    TCP_NEW_SYN_RECV:
    sk = req->rsk_listener
    sock_hold(sk)
    /* No lock on listener */
                               smc_close_active():
                                 write_lock_bh(cb_lock)
                                 sk_user_data = NULL
                                 write_unlock_bh(cb_lock)
                                 ...
                                 smc_clcsock_release()
                                 sock_put(smc->sk) x2
                                   -> smc_sock freed!
    tcp_check_req()
      smc_tcp_syn_recv_sock():
        smc = user_data(sk)
          -> NULL or dangling
        smc->queued_smc_hs
          -> crash!
net/smc/smc.h +0 -0
index 9e6af72784ba..8b3eabcdb542 100644

net/smc/smc.h static inline void smc_init_saved_callbacks(struct smc_sock *smc) · line 346

Quoted 7 lines
net/smc/smc.h +1 -2
@@ -342,8 +342,7 @@ static inline void smc_init_saved_callbacks(struct smc_sock *smc)
 
 static inline struct smc_sock *smc_clcsock_user_data(const struct sock *clcsk)
 {
-       return (struct smc_sock *)
-              ((uintptr_t)clcsk->sk_user_data & ~SK_USER_DATA_NOCOPY);
+       return (struct smc_sock *)rcu_dereference_sk_user_data(clcsk);
 }

Are you sure all smc_clcsock_user_data() callers hold rcu_read_lock() ? In order to avoid surprises, I would have added a new helper.

static inline struct smc_sock *smc_clcsock_user_data_rcu(const struct
sock *clcsk)
...

to allow gradual conversion ?

Thanks !

author
#2 lore raw
Quoted 62 lines · Eric Dumazet
Quoted 51 lines · Jiayuan Chen

From: Jiayuan Chen <[email protected]>

Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].

smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release().

This leads to two issues:

1) NULL pointer dereference: sk_user_data is NULL when accessed.
2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.

The race window looks like this:

   CPU A (softirq)              CPU B (process ctx)

   tcp_v4_rcv()
     TCP_NEW_SYN_RECV:
     sk = req->rsk_listener
     sock_hold(sk)
     /* No lock on listener */
                                smc_close_active():
                                  write_lock_bh(cb_lock)
                                  sk_user_data = NULL
                                  write_unlock_bh(cb_lock)
                                  ...
                                  smc_clcsock_release()
                                  sock_put(smc->sk) x2
                                    -> smc_sock freed!
     tcp_check_req()
       smc_tcp_syn_recv_sock():
         smc = user_data(sk)
           -> NULL or dangling
         smc->queued_smc_hs
           -> crash!
net/smc/smc.h +0 -0
index 9e6af72784ba..8b3eabcdb542 100644

net/smc/smc.h static inline void smc_init_saved_callbacks(struct smc_sock *smc) · line 346

Quoted 7 lines
net/smc/smc.h +1 -2
@@ -342,8 +342,7 @@ static inline void smc_init_saved_callbacks(struct smc_sock *smc)
 
  static inline struct smc_sock *smc_clcsock_user_data(const struct sock *clcsk)
  {
-       return (struct smc_sock *)
-              ((uintptr_t)clcsk->sk_user_data & ~SK_USER_DATA_NOCOPY);
+       return (struct smc_sock *)rcu_dereference_sk_user_data(clcsk);
  }

Are you sure all smc_clcsock_user_data() callers hold rcu_read_lock() ? In order to avoid surprises, I would have added a new helper.

Quoted 7 lines

static inline struct smc_sock *smc_clcsock_user_data_rcu(const struct
sock *clcsk)
...

to allow gradual conversion ?

Thanks !

Sorry I missed that.

pw-bot: cr

syzbot Tested-by [email protected] on v3 1/1
#3 lore raw
In reply to Jiayuan Chen
syzbot ci has tested the following series

syzbot ci has tested the following series

[v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()
https://lore.kernel.org/all/[email protected]
* [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()

and found the following issues:
* WARNING: suspicious RCU usage in smc_fback_error_report
* WARNING: suspicious RCU usage in smc_fback_state_change
* WARNING: suspicious RCU usage in smc_fback_write_space

Full report is available here:
https://ci.syzbot.org/series/b6883213-02f6-437e-bb3b-09fc59b0534c

***

WARNING: suspicious RCU usage in smc_fback_error_report

tree:      net
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net.git
base:      73aefba4e2eb713cf7bc4ad83cfc9b5d4f966f6d
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/0ecfc74c-85c7-4a7b-8b09-d322ac9ea108/config
C repro:   https://ci.syzbot.org/findings/f8c698ca-41b9-4ced-953c-f6c3ee405ebc/c_repro
syz repro: https://ci.syzbot.org/findings/f8c698ca-41b9-4ced-953c-f6c3ee405ebc/syz_repro

=============================
WARNING: suspicious RCU usage
syzkaller #0 Not tainted
-----------------------------
./include/net/sock.h:682 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz.0.17/5970:
#0: ffff88811a1d1d60 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1709 [inline] #0: ffff88811a1d1d60 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: inet_stream_connect+0x51/0xa0 net/ipv4/af_inet.c:749 #1: ffff88811a1d1f08 (k-clock-AF_INET6){++..}-{3:3}, at: smc_fback_error_report+0x2d/0x140 net/smc/af_smc.c:900

stack backtrace:
CPU: 0 UID: 0 PID: 5970 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 lockdep_rcu_suspicious+0x13f/0x1d0 kernel/locking/lockdep.c:6876
 __rcu_dereference_sk_user_data_with_flags include/net/sock.h:682 [inline]
 smc_clcsock_user_data net/smc/smc.h:345 [inline]
 smc_fback_error_report+0x135/0x140 net/smc/af_smc.c:901
 sk_error_report+0x48/0x2b0 net/core/sock.c:348
 tcp_disconnect+0x132c/0x1fa0 net/ipv4/tcp.c:3543
 __inet_stream_connect+0x32b/0xdd0 net/ipv4/af_inet.c:648
 inet_stream_connect+0x66/0xa0 net/ipv4/af_inet.c:750
 __sys_connect_file net/socket.c:2089 [inline]
 __sys_connect+0x312/0x450 net/socket.c:2108
 __do_sys_connect net/socket.c:2114 [inline]
 __se_sys_connect net/socket.c:2111 [inline]
 __x64_sys_connect+0x7a/0x90 net/socket.c:2111
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7effcfd9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe9219fa18 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007effd0015fa0 RCX: 00007effcfd9c799
RDX: 000000000000000c RSI: 00002000000001c0 RDI: 0000000000000003
RBP: 00007effcfe32bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007effd0015fac R14: 00007effd0015fa0 R15: 00007effd0015fa0
 </TASK>

***

WARNING: suspicious RCU usage in smc_fback_state_change

tree:      net
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net.git
base:      73aefba4e2eb713cf7bc4ad83cfc9b5d4f966f6d
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/0ecfc74c-85c7-4a7b-8b09-d322ac9ea108/config
C repro:   https://ci.syzbot.org/findings/fb044c1b-44f5-483a-bb87-1aad71a75a03/c_repro
syz repro: https://ci.syzbot.org/findings/fb044c1b-44f5-483a-bb87-1aad71a75a03/syz_repro

=============================
WARNING: suspicious RCU usage
syzkaller #0 Not tainted
-----------------------------
./include/net/sock.h:682 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
3 locks held by syz.0.17/5945:
#0: ffff8881be8b0ee0 (sk_lock-AF_SMC){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1709 [inline] #0: ffff8881be8b0ee0 (sk_lock-AF_SMC){+.+.}-{0:0}, at: smc_sendmsg+0x52/0x4d0 net/smc/af_smc.c:2802 #1: ffff8881b9f04360 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1709 [inline] #1: ffff8881b9f04360 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x21/0x50 net/ipv4/tcp.c:1464 #2: ffff8881b9f04508 (k-clock-AF_INET){++..}-{3:3}, at: smc_fback_state_change+0x2d/0x140 net/smc/af_smc.c:864

stack backtrace:
CPU: 1 UID: 0 PID: 5945 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 lockdep_rcu_suspicious+0x13f/0x1d0 kernel/locking/lockdep.c:6876
 __rcu_dereference_sk_user_data_with_flags include/net/sock.h:682 [inline]
 smc_clcsock_user_data net/smc/smc.h:345 [inline]
 smc_fback_state_change+0x135/0x140 net/smc/af_smc.c:865
 tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:7000 [inline]
 tcp_rcv_state_process+0x2b23/0x4810 net/ipv4/tcp_input.c:7215
 tcp_v4_do_rcv+0x6bb/0x1430 net/ipv4/tcp_ipv4.c:1907
 sk_backlog_rcv include/net/sock.h:1185 [inline]
 __release_sock+0x265/0x3a0 net/core/sock.c:3213
 release_sock+0x5f/0x1f0 net/core/sock.c:3795
 tcp_sendmsg+0x39/0x50 net/ipv4/tcp.c:1466
 smc_sendmsg+0x250/0x4d0 net/smc/af_smc.c:2823
 sock_sendmsg_nosec net/socket.c:727 [inline]
 __sock_sendmsg net/socket.c:742 [inline]
 ____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
 __sys_sendmsg net/socket.c:2678 [inline]
 __do_sys_sendmsg net/socket.c:2683 [inline]
 __se_sys_sendmsg net/socket.c:2681 [inline]
 __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f9b66d9c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe630639c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f9b67015fa0 RCX: 00007f9b66d9c799
RDX: 00000000200048cc RSI: 0000200000000240 RDI: 0000000000000003
RBP: 00007f9b66e32bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f9b67015fac R14: 00007f9b67015fa0 R15: 00007f9b67015fa0
 </TASK>

***

WARNING: suspicious RCU usage in smc_fback_write_space

tree:      net
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net.git
base:      73aefba4e2eb713cf7bc4ad83cfc9b5d4f966f6d
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/0ecfc74c-85c7-4a7b-8b09-d322ac9ea108/config
C repro:   https://ci.syzbot.org/findings/a3f8aa1e-ebea-41f3-b6e4-97d45bc19aaf/c_repro
syz repro: https://ci.syzbot.org/findings/a3f8aa1e-ebea-41f3-b6e4-97d45bc19aaf/syz_repro

=============================
WARNING: suspicious RCU usage
syzkaller #0 Not tainted
-----------------------------
./include/net/sock.h:682 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz.0.17/5953:
#0: ffff8881b9ed1c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1709 [inline] #0: ffff8881b9ed1c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1152 [inline] #0: ffff8881b9ed1c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: sk_setsockopt+0xe62/0x2e80 net/core/sock.c:1310 #1: ffff8881b9ed1e08 (k-clock-AF_INET){++..}-{3:3}, at: smc_fback_write_space+0x2d/0x140 net/smc/af_smc.c:888

stack backtrace:
CPU: 1 UID: 0 PID: 5953 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 lockdep_rcu_suspicious+0x13f/0x1d0 kernel/locking/lockdep.c:6876
 __rcu_dereference_sk_user_data_with_flags include/net/sock.h:682 [inline]
 smc_clcsock_user_data net/smc/smc.h:345 [inline]
 smc_fback_write_space+0x135/0x140 net/smc/af_smc.c:889
 sk_setsockopt+0x221f/0x2e80 net/core/sock.c:1351
 do_sock_setsockopt+0x11b/0x1b0 net/socket.c:2318
 __sys_setsockopt net/socket.c:2347 [inline]
 __do_sys_setsockopt net/socket.c:2353 [inline]
 __se_sys_setsockopt net/socket.c:2350 [inline]
 __x64_sys_setsockopt+0x13d/0x1b0 net/socket.c:2350
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0c5f39c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd35759278 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007f0c5f615fa0 RCX: 00007f0c5f39c799
RDX: 0000000000000020 RSI: 0000000000000001 RDI: 0000000000000003
RBP: 00007f0c5f432bd9 R08: 0000000000000004 R09: 0000000000000000
R10: 0000200000000100 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f0c5f615fac R14: 00007f0c5f615fa0 R15: 00007f0c5f615fa0
 </TASK>

***

If these findings have caused you to resend the series or submit a separate fix, please add the following tag to your commit message:

Tested-by [email protected]

---
This report is generated by a bot. It may contain errors. syzbot ci engineers can be reached at [email protected].