From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC9C7305968 for ; Tue, 12 May 2026 04:20:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778559649; cv=none; b=C5kCkmLYolBPNl4copjcE9oKC/Rdcz/yMcvwAz+eJKYE3nHlfy/chql+EnkKZzpm3FRjOvX/KrAnp1PpFfp6ZxSz30yyYbRdl+P02zOFenajdRb5qt06tBV8xbaGKGbJej11igzzCt5BbkmH73neiZ299rdS9nyeI6kakIQ7+9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778559649; c=relaxed/simple; bh=WHiesOwbbaRykJfdtVDyeKoOa5KVbxP/VHmih9skOVc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WAnuVjaWI3nKR09gq4wDCVdNA1QQKTlAOworlDPW7pqmxThUuADglYS+/8Hn/hZg7yGv9Ec5EYtel9XrXHh3sfzsoIFf3eUYOO8WxI0p8tiHk0wyHzO93Vnj9VahsBkG2FTK4cU3ImCi3Qw+3t8V+KZYvFNd0jLW7viIeANTCgg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=mf1vjOfv; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mf1vjOfv" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-48896199cbaso45513515e9.1 for ; Mon, 11 May 2026 21:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778559646; x=1779164446; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+rA8ducxret8G6zv/e1/Fv9YIi0bNAE6NW5UJ1HwACA=; b=mf1vjOfvfPJpLd9NIG+vH5GU+xB0x19CJirg6mbPMQyTThRrVHXR4xr2UBkgCPKJWT ZgUL+ymWa4bUj3lptEDaB5csr8uplgc2YGBJlyvTL9Gm43LXXveygFhW0+b4aWj2/OVG dwI81UmD8Nl0GblPtXPZmFaHjeYnr9I6w6ducXJlh2wN7P2AIp65xlUDE82Bnc1Yh3go UTMVfOX7IRgp6jBl8qKMWhXhxH+Zb8ZLYJ8u9yuozZG6ZbKDWPj3PAu4bhZELvuyqNF7 BOSf/zz7o/RBgbDfr/vkVx9gGVzOkiBDjI46XdouSfaSbG6ixO/KVsZFSgwJ0lGQa/7b tLzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778559646; x=1779164446; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+rA8ducxret8G6zv/e1/Fv9YIi0bNAE6NW5UJ1HwACA=; b=kssW2tZ4ZjMwnXDt/dcnjZSExsIJ7LSaebuLSdPOY1T3aerktT0upyb317kbE4SNqA E1gKP6omzbRvpsGTKeFvQIHgp1/JHcEOjo79evZIp1hUz7TIMwbLdO1qLvEZCuUSwMMf Ihiy4ZXHrXANtdWtDaYysbvxBQZLKmPU5bgIshVzytVk2l2a/KVRcLumGGTwlTwIwAim B/+ll2FAx5mQlSGGs78+GpcjFNHF5MHcQ7XyftH0f/Tn/p5balBTySAh38VQQWlrxpKf IC49rM931XyVSGufR1XiCGPh2ydaKa6IQ0C1EECj0TZJ8oJjIrIr/z9y+CNeBGBnk8BR jntQ== X-Forwarded-Encrypted: i=1; AFNElJ9aMgEdShflnI+qFnDcqZyZFI+qcIp6TqeQOW5TsjXgTU0oZO+j0N7GYhg459v93CTRqYwJOXsETtOMrlM=@vger.kernel.org X-Gm-Message-State: AOJu0YwH0daX29Jgnxz42LpOQV7ypA2sqz/7TEwDkKYpObUZrOGXQyLD BToJuuBB9ZCwGKftMmyuIZicoBEk8v4n2Wp5bvizj8VhQ3X8vuIbyE5YEOqfCIxs3Ud4gA== X-Gm-Gg: Acq92OFVPU2Z9SGx+PghFzTYDCiACeC+Nqh2oPhcY2oVXool8OsZvm9lNugkLv+kE2f 3/Kgoh3ZY7faYCptl7Hj9gE9npbSdKCc2WKwU1FcjlqokSvjsNMtsnTfywUEXtGeZXC/aSnwSQr YY5+UoA0Bbd6aQZPhUV061OCJRjL/4rOiwhpt069xPtSuOAD9KfI1f/ikGcKuRkMA/cfblOxM7a WGQu3ZBcRFOkWF+XqR7bTySOdkdI5sZXb3EO+XpcKKQk5G5QkNvMZVaLinBDFZCUZDxJkxChoGD QOB+bPAV+CAQdbsUIVgVgDiTZBSNzJsJUUeTA3L6oAZl8GvLN77gWxQCo1jj+bazDQR2N1E+3KP VRZE/pgNX5RLNEvkP61iTCScKx8YBoVtUk3nRY78yv/yvOAR4OnRG9pkgRIm9ewCzfD2fuFSwNP dOVpuIp53rrDfEWiyJl+VAGe7BJPAMCocTPA2Q5ZLLAMdAldFSxthZWu83ZIuhu3OU54E95VI0z tsodG19iAM= X-Received: by 2002:a05:600c:8207:b0:48e:82cc:4d4c with SMTP id 5b1f17b1804b1-48e8fe7cfa1mr15556645e9.23.1778559645692; Mon, 11 May 2026 21:20:45 -0700 (PDT) Received: from dohko.chello.ie (188-141-5-72.dynamic.upc.ie. [188.141.5.72]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e908d2c77sm16802215e9.12.2026.05.11.21.20.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 21:20:44 -0700 (PDT) From: David Carlier To: netdev@vger.kernel.org Cc: David Carlier , Antonio Quartulli , Sabrina Dubroca , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-kernel@vger.kernel.org Subject: [PATCH net 1/2] ovpn: tcp - use cached peer pointer in ovpn_tcp_close() Date: Tue, 12 May 2026 05:19:12 +0100 Message-ID: <20260512042036.19870-2-devnexen@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260512042036.19870-1-devnexen@gmail.com> References: <20260512042036.19870-1-devnexen@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data() under rcu_read_lock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpn_peer_del(), re-dereferencing the ovpn_socket after the RCU read section has ended. Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by lock_sock() held across the function, ovpn_tcp_close() runs without the socket lock: inet_release() invokes sk_prot->close() without taking lock_sock first. ovpn_socket_release() can therefore complete its kref_put -> detach -> synchronize_rcu -> kfree(sock) sequence concurrently, in the window after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences sock->peer. The synchronize_rcu() in ovpn_socket_release() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards. A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sk_socket member after tcp_close()"): trigger a peer removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim. Use the already-loaded peer local, which is held by the ovpn_peer_hold() taken under RCU and is the correct argument anyway. The remaining lines in the function already use peer; switching this call makes the function consistent and removes the dangling sock dereference. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: David Carlier --- drivers/net/ovpn/tcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ovpn/tcp.c b/drivers/net/ovpn/tcp.c index 65054cc84be5..ed4782de141a 100644 --- a/drivers/net/ovpn/tcp.c +++ b/drivers/net/ovpn/tcp.c @@ -588,7 +588,7 @@ static void ovpn_tcp_close(struct sock *sk, long timeout) peer = sock->peer; rcu_read_unlock(); - ovpn_peer_del(sock->peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT); + ovpn_peer_del(peer, OVPN_DEL_PEER_REASON_TRANSPORT_DISCONNECT); peer->tcp.sk_cb.prot->close(sk, timeout); ovpn_peer_put(peer); } -- 2.53.0