* [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()
@ 2026-03-10 12:00 Jiayuan Chen
2026-03-10 12:13 ` Eric Dumazet
2026-03-10 23:15 ` [syzbot ci] " syzbot ci
0 siblings, 2 replies; 4+ messages in thread
From: Jiayuan Chen @ 2026-03-10 12:00 UTC (permalink / raw)
To: netdev
Cc: Jiayuan Chen, syzbot+827ae2bfb3a3529333e9, Eric Dumazet,
Jiayuan Chen, D. Wythe, Dust Li, Sidraya Jayagond, Wenjia Zhang,
Mahanta Jambigi, Tony Lu, Wen Gu, David S. Miller, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-rdma, linux-s390, linux-kernel
From: Jiayuan Chen <jiayuan.chen@shopee.com>
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: syzbot+827ae2bfb3a3529333e9@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/67eaf9b8.050a0220.3c3d88.004a.GAE@google.com/T/
Suggested-by: Eric Dumazet <edumazet@google.com>
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
---
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/20260309023846.18516-1-jiayuan.chen@linux.dev/
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/20260307032158.372165-1-jiayuan.chen@linux.dev/
---
net/smc/af_smc.c | 19 ++++++++++++++-----
net/smc/smc.h | 3 +--
net/smc/smc_close.c | 2 +-
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index d0119afcc6a1..078927ba068a 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -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;
diff --git a/net/smc/smc.h b/net/smc/smc.h
index 9e6af72784ba..8b3eabcdb542 100644
--- a/net/smc/smc.h
+++ b/net/smc/smc.h
@@ -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 */
diff --git a/net/smc/smc_close.c b/net/smc/smc_close.c
index 10219f55aad1..bb0313ef5f7c 100644
--- a/net/smc/smc_close.c
+++ b/net/smc/smc_close.c
@@ -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);
}
--
2.43.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()
2026-03-10 12:00 [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Jiayuan Chen
@ 2026-03-10 12:13 ` Eric Dumazet
2026-03-10 12:38 ` Jiayuan Chen
2026-03-10 23:15 ` [syzbot ci] " syzbot ci
1 sibling, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2026-03-10 12:13 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, Jiayuan Chen, syzbot+827ae2bfb3a3529333e9, D. Wythe,
Dust Li, Sidraya Jayagond, Wenjia Zhang, Mahanta Jambigi, Tony Lu,
Wen Gu, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-rdma, linux-s390, linux-kernel
On Tue, Mar 10, 2026 at 1:01 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> 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!
>
> diff --git a/net/smc/smc.h b/net/smc/smc.h
> index 9e6af72784ba..8b3eabcdb542 100644
> --- a/net/smc/smc.h
> +++ b/net/smc/smc.h
> @@ -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 !
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()
2026-03-10 12:13 ` Eric Dumazet
@ 2026-03-10 12:38 ` Jiayuan Chen
0 siblings, 0 replies; 4+ messages in thread
From: Jiayuan Chen @ 2026-03-10 12:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Jiayuan Chen, syzbot+827ae2bfb3a3529333e9, D. Wythe,
Dust Li, Sidraya Jayagond, Wenjia Zhang, Mahanta Jambigi, Tony Lu,
Wen Gu, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-rdma, linux-s390, linux-kernel
On 3/10/26 8:13 PM, Eric Dumazet wrote:
> On Tue, Mar 10, 2026 at 1:01 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>>
>> 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!
>>
>
>
>> diff --git a/net/smc/smc.h b/net/smc/smc.h
>> index 9e6af72784ba..8b3eabcdb542 100644
>> --- a/net/smc/smc.h
>> +++ b/net/smc/smc.h
>> @@ -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 !
Sorry I missed that.
pw-bot: cr
^ permalink raw reply [flat|nested] 4+ messages in thread
* [syzbot ci] Re: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()
2026-03-10 12:00 [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Jiayuan Chen
2026-03-10 12:13 ` Eric Dumazet
@ 2026-03-10 23:15 ` syzbot ci
1 sibling, 0 replies; 4+ messages in thread
From: syzbot ci @ 2026-03-10 23:15 UTC (permalink / raw)
To: alibuda, davem, dust.li, edumazet, guwen, horms, jiayuan.chen,
jiayuan.chen, kuba, linux-kernel, linux-rdma, linux-s390,
mjambigi, netdev, pabeni, sidraya, syzbot, tonylu, wenjia
Cc: syzbot, syzkaller-bugs
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/20260310120053.136594-1-jiayuan.chen@linux.dev
* [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: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-03-10 23:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-10 12:00 [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Jiayuan Chen
2026-03-10 12:13 ` Eric Dumazet
2026-03-10 12:38 ` Jiayuan Chen
2026-03-10 23:15 ` [syzbot ci] " syzbot ci
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox