From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20F973DC4A4 for ; Tue, 10 Mar 2026 12:38:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773146322; cv=none; b=qQ4kGic8ePzdkrSSZgpao1dpJUjyc+GNhwiOsY0ndsUUqsvh8ciilGiGzEkO5pzr7kLQFNDM9WegRet6cNcja+5+DPDAs+t/cTlnI7ETGvl/EowrD+319I3iNfRN9Gv0fKTbk5LYoxgq1d/mKFBEg4AIfDiME+XjVS6/w0W//fg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773146322; c=relaxed/simple; bh=CTpIvISwHm/A71DqOvdlv0hatiRYcvynfbWDp7A7wDw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CwnOSS3UKb32BsNFhUwhTJm6sV8eBPdgA5Pclg3daTM39LvBdZHzx2mvebdM+zoaKUnKiUBQ4tPtFgdB6+2/+OBkaiVL3thq1anaFiDbYNLguN0bt5HNbo+17ZiY3eRdinfHqKnClLEWBQHP3ZTYWtV0j1ZZa/25zFw57Q9KfUk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=mE96N4l2; arc=none smtp.client-ip=95.215.58.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="mE96N4l2" Message-ID: <270e708d-cb52-413c-860e-16945ae98012@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773146309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jDizjKfKLjRprs2izCP8nlt9BhCmmNO1wOtyhYNrASw=; b=mE96N4l2+SLN8WLkJ+TFSdj/gGYT0r4bavqiVkrIaKOFpw6fh3BqVgYNCOGLaHLdA46nhW zO9fO0g0ZztDJp9QtBKNmLzJhvSKECRVukAcO5jqRWZHGsaPkeVUMqo1wpMn5sQamnSdW9 JX/MXfIuVvfYRSyvTOkguCBW+rgyetE= Date: Tue, 10 Mar 2026 20:38:10 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net v3] net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() To: Eric Dumazet Cc: netdev@vger.kernel.org, Jiayuan Chen , syzbot+827ae2bfb3a3529333e9@syzkaller.appspotmail.com, "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@vger.kernel.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260310120053.136594-1-jiayuan.chen@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jiayuan Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 3/10/26 8:13 PM, Eric Dumazet wrote: > On Tue, Mar 10, 2026 at 1:01 PM Jiayuan Chen wrote: >> From: Jiayuan Chen >> >> 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