From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.86 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793527381; b=NumiKDrR5dHsH2wYi3OakXr1iS+BNSwth42v7KIb+UoOq4aflPkdbJp0HqV3CUKjGDXr yMHScCfW/1/JGyNJF+RpCChZUVO7Izy4p370DCfLOq3bCQAqCra931BaW1IBp+IGT2ct+ hkyC3cgKm/X7r/Z/Bp/DHTAZUXhrRhspVnd0rHxl45Q4tF9SC2GrFPXunBYMqYGZwKw8V YTuM93oe8QyDdxdtPd39eBqSc5AFOg9UjDzLXpdLW5a4N0qN2yTTUXPbdtcqxCVLuDfKb B1RY70KrLEg2E/WlOXE5kkSKxkY/R/+oVfYfeAbxKzxRbOVXd728FDyhkLj7uOiqb6Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793527381; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=CcUb3OEvt4a1yV7+AYfYcqheRryY6o0DxYaBOwnyDcA=; b=2Spqpq40K4raLzFye8B2nSOuQdr4jGyWgDWYPpK7NNyXPdq+NmhWZdaVbHV/wKa1Rfd5 ClVY0v90mnZkghRxo6A0FWRoF1m3ycruiXLl3A8vafDHTQK7E2Pv/wlXJnz9Gb1RZIkhM lHpqQJUPKZWVQ0ZD0LZQUe+Byn1T5tim/NkmSzq36Be6Mps7yjGh5qfrsHAx+X/zv6s2l xeH0PKWjWdYpH5qjqBxevdBhQ14zLQO8mWmYLzqHnA+luDbnfvbAW/jv3J86FeAhtDlQW BBW7ZMzYPYyLwkLDYbQMHPCqj9lgkh6MzSSkCUGwlEGEvNhGLzD9sc0hanTnr5xC7HQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=bkok4EIA; arc=none smtp.remote-ip=91.218.175.86 Received: from mta0.migadu.com (out-86.mta0.migadu.com [91.218.175.86]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33787606A325 for ; Sun, 1 Nov 2026 10:02:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 33787606A325 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, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=bkok4EIA X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=yYCz03GhobTxtAJpUtamnKh4J2bHZRJOFBYPZ9SOXn0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793527376; v=1; x=1794132176; b=bkok4EIA52/J3efDJoMJVfywKr7US22/DAlWiNqZKvXQnnAEwwOsmbWg8vLsWZgXfPE1v1lE 8WWh9/sMEvo7+aoQCBrofccYLf6BWEH5Pp/hXJnfxRqgXISey80Lv3f+mRKsjj88tOZpZq5Brp3 NhhDWjlsBG1IszXRmX6Etf3s= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 7d86e53af7001ace; Sun, 01 Nov 2026 10:02:56 +0000 X-Mizu-Trace-ID: 7d86e53af7001ace X-Migadu-Flow: FLOW_OUT Message-ID: <062d02ca-e9e1-4f4e-ac57-0de27272a205@linux.dev> Date: Sun, 1 Nov 2026 18:02:48 +0800 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] tcp: fix device binding after failed IPv6 connect To: Xia Yan , netdev@vger.kernel.org Cc: edumazet@kernel.org, ncardwell@google.com, kuniyu@google.com, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, yana06070@163.com References: <20261031074654.73952-1-yanxia@cmss.chinamobile.com> From: Jiayuan Chen In-Reply-To: <20261031074654.73952-1-yanxia@cmss.chinamobile.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10/31/26 3:46 PM, Xia Yan wrote: > tcp_v6_connect() sets sk_bound_dev_if from sin6_scope_id when connecting > to a link-local address. If the route lookup fails, the failure path > clears the destination port and route capabilities but leaves the > device binding in place. > > A failed connection through a down interface can therefore leave the > socket bound to that interface. A subsequent connect() on the same > socket to ::1 then fails with ENETUNREACH, even though a fresh socket > can reach the listener. > > Save the original device binding before processing the destination and > restore it on failure. > > Found while reviewing the error paths in tcp_v6_connect(). Reproduced > in UML by connecting to fe80::1 on a down dummy interface, then retrying > the same socket against a listener on ::1. With the fix, the retry > succeeds and data flows in both directions. Tests also confirm that > existing device bindings are retained after failed IPv6, IPv4-mapped > and link-local connections without an explicit scope ID. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@vger.kernel.org > Signed-off-by: Xia Yan > --- > > Tested in UML on net fcc00b15cb21. The complete tcp_ipv6.c file is > unchanged at the base commit. Before the fix, the socket remains > bound after the failed link-local connect and cannot reconnect. > With the fix, all 12 checks pass. > > Build-tested on x86_64 with W=1 using configurations based on > allmodconfig and allyesconfig. The corrected tcp_ipv6.o compiles > without warnings in both configurations, and incremental kernel > builds complete successfully. WERROR was disabled for both; > allyesconfig also had KUNIT_ALL_TESTS disabled. > > net/ipv6/tcp_ipv6.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c > index e006a30360eae..7bb8266d9d1b7 100644 > --- a/net/ipv6/tcp_ipv6.c > +++ b/net/ipv6/tcp_ipv6.c > @@ -146,6 +146,7 @@ static int tcp_v6_connect(struct sock *sk, struct sockaddr_unsized *uaddr, > struct flowi6 *fl6; > int addr_type; > int err; > + int old_bound_dev_if = READ_ONCE(sk->sk_bound_dev_if); > Reverse xmas tree please > if (addr_len < SIN6_LEN_RFC2133) > return -EINVAL; > @@ -358,6 +359,7 @@ late_failure: > failure: > inet->inet_dport = 0; > sk->sk_route_caps = 0; > + WRITE_ONCE(sk->sk_bound_dev_if, old_bound_dev_if); inet_bhash2_reset_saddr uses sk_bound_dev_if too.   inet_bhash2_reset_saddr     __inet_bhash2_update_saddr       inet_sk_bound_l3mdev So I think we should restore it before  inet_bhash2_reset_saddd ?