From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (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 E26A43815E3 for ; Mon, 1 Jun 2026 23:15:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780355749; cv=none; b=sT6T4WJo+TtAmYMZCCMzg7Cbdi0cCHXKNIcWQbTmWkpwjlCm++u9RgJryHK0ql9mjfifD4I1zPpszi9VOfBHatQXb/nmFAp+UQCrhXIzrPEBzN0w2LPLJ8DdDIK0Vd3mFJOhu2B5UhFuhpklAhl17AWKoAPBHW1HmaFctq1jk00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780355749; c=relaxed/simple; bh=lqhOs9ZM01+8ZAhlMBS+uwgzvfPH+kIaLFt0q7E0uME=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=RqnovK8JqSaTLq/B6DfbEKW8SmmLhS0jRmIi8UdcAKt3aB/q4lkfV5vW3saUfpTxVZWoxwwkQvNXyQBxo2AEQjcY2+qEJLy3QZVxIqwFBRGLmrnugBrtMJXDy7H8gcerU7bkM1lvx9xQJ7rm58oaIO2qx1/xWEXhq1RGivmWKSc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--kuniyu.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Cgzx5hQa; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--kuniyu.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Cgzx5hQa" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c85a2f1d1e5so1125405a12.3 for ; Mon, 01 Jun 2026 16:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780355747; x=1780960547; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=+MPs5VOvWTvAVcAJdSu8P1ANlCnfNEQ27RwpDFiLF0Y=; b=Cgzx5hQayxlGdrScZi/j2eZ7jn/gAAOHq5vKECAPzHtrpjiTL5FeJFnYF4rr06RSZ1 NmQo4eE+EZdvvKc/px2XuKwoeAhyjl5LcDoeq5b8pi63lHhKFi/j2dQXqiHqcmcWkvU+ MXP66GUOnsb3g5/teKwKbYQ5Lk5iJjujly0iajz1yJpbkNNzFSZsPxrpqr+RfH1F3C5H eK5BsFis/BZj8LRk8Z9tioPq6lrY5wmug6+Ji8CFQmNUxlbAPuMOyyh9uGSECU5SJd0N ZDtzBg9+5NBrjUP6NIylPstsoh7B2s49UTZ6yYnLWTpw3jKoXVZbaKz4OGVGFUYvVxgs W+oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780355747; x=1780960547; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=+MPs5VOvWTvAVcAJdSu8P1ANlCnfNEQ27RwpDFiLF0Y=; b=b44ur6tt0cN3L6gIDX+Mu/5XeAFKYZckabnn83KJt8uXqleKfeRvSKlIUSTHRweRzm eSvG8pGCPsEU/HgDLow1S7LaHUjcRjhRFF03Vd6rWcFndKxTZ+8iwIz8NxJbWeEZeRLO yE9/Qp/umC1xlS6JexrIySrRm/aj2pG5EoKLgLA1RO3OMXOvWY7lz2t6rhNbfD2ytSFo Y+MkcrIg7Mg7TCEADxlC2lB5TXRoYIIQG4heB7RgqSInps0eTPFoFHiTyQ3BvslInzgY l1Xksskdr/xopzsbP9zJBLRk8Yh7lu2yO1KrhlIDL8+yxNu8kvKIlta4tqHOmIkqjFYT AH5A== X-Forwarded-Encrypted: i=1; AFNElJ+mt5t+8UjQlYb7cqYnyVnnKGhQonagEY/kH43g0wDEHRdOTbghiQ0EDTiEDSqoNbx0TxvrWBH2WCBnvsI=@vger.kernel.org X-Gm-Message-State: AOJu0YwZxPA5UGyCwQSLVPtlHcgdJYCMz/n3aJZ14OoXqHmEUiipl7Lg e4jBk1bdlc7t761VpTCLHEHsyVhXEzHsq7ztmraxyy4Rjn32S0vBLbZ32ZbQOep6gjlLLbdsseX ih6PuMA== X-Received: from plgw12.prod.google.com ([2002:a17:902:e88c:b0:2bf:33cb:e3a4]) (user=kuniyu job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:390f:b0:2bd:8395:fedd with SMTP id d9443c01a7336-2bf36875f57mr151102895ad.37.1780355746881; Mon, 01 Jun 2026 16:15:46 -0700 (PDT) Date: Mon, 1 Jun 2026 23:14:44 +0000 In-Reply-To: <20260601223122.63c0d23f@pumpkin> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260601223122.63c0d23f@pumpkin> X-Mailer: git-send-email 2.54.0.929.g9b7fa37559-goog Message-ID: <20260601231546.3407019-1-kuniyu@google.com> Subject: Re: [PATCH net] ipv6: use READ_ONCE() in ipv6_flowlabel_get() From: Kuniyuki Iwashima To: david.laight.linux@gmail.com Cc: davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, horms@kernel.org, idosch@nvidia.com, jianhao.xu@seu.edu.cn, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, runyu.xiao@seu.edu.cn, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable From: David Laight Date: Mon, 1 Jun 2026 22:31:22 +0100 > On Mon, 1 Jun 2026 05:36:37 -0700 > Eric Dumazet wrote: >=20 > > On Mon, Jun 1, 2026 at 5:22=E2=80=AFAM David Laight > > wrote: > > > > > > On Sun, 31 May 2026 23:39:46 +0800 > > > Runyu Xiao wrote: > > > =20 > > > > ipv6_flowlabel_get() still reads the shared per-net sysctl fields > > > > flowlabel_consistency and flowlabel_state_ranges with plain loads, > > > > while writers update them through proc_dou8vec_minmax(). These chec= ks > > > > run in the live IPV6_FLOWLABEL_MGR path, so lockless plain reads le= ave > > > > KCSAN-visible data races and can make the policy checks observe sta= le or > > > > inconsistent values. > > > > > > > > The race can be reached on a running system by toggling > > > > /proc/sys/net/ipv6/flowlabel_consistency and > > > > /proc/sys/net/ipv6/flowlabel_state_ranges while another task repeat= edly > > > > issues IPV6_FLOWLABEL_MGR requests with IPV6_FL_F_REFLECT or a > > > > state-ranges flow label. > > > > > > > > This issue was first flagged by our static analysis tool while scan= ning > > > > lockless IPv6 sysctl readers, then manually audited on Linux v6.18.= 21. > > > > The IPV6_FLOWLABEL_MGR paths were runtime-reproduced with QEMU/KCSA= N by > > > > concurrently flipping the two sysctls while TCP reflect and UDP > > > > state-ranges setsockopt actors exercised ipv6_flowlabel_get(). KCSA= N > > > > reported races between proc_dou8vec_minmax() and the two plain-load > > > > sites in ipv6_flowlabel_get(). > > > > > > > > A narrower second-round UDPv6 + IPV6_AUTOFLOWLABEL send-side reprod= ucer > > > > also hit the inline ip6_make_flowlabel() reader through > > > > __ip6_make_skb() / proc_dou8vec_minmax(), but that site is already > > > > fixed in this tree by commit ded139b59b5d > > > > ("ipv6: annotate data-races from ip6_make_flowlabel()"). The remain= ing > > > > plain readers in this tree are both in ipv6_flowlabel_get(). > > > > > > > > Use READ_ONCE() for those remaining sysctl reads so they follow the= same > > > > lockless reader contract already used by other IPv6 sysctl readers. > > > > > > > > Build-tested by compiling net/ipv6/ip6_flowlabel.o on x86_64. > > > > > > > > Representative QEMU/KCSAN reports from the two target reader paths: > > > > > > > > BUG: KCSAN: data-race in ipv6_flowlabel_opt / proc_dou8vec_minmax > > > > write: proc_dou8vec_minmax+0x206/0x220 > > > > read: ipv6_flowlabel_opt+0x6d8/0xd20 > > > > do_ipv6_setsockopt+0x873/0x2220 > > > > tcp_setsockopt+0x72/0xb0 > > > > > > > > BUG: KCSAN: data-race in ipv6_flowlabel_opt / proc_dou8vec_minmax > > > > write: proc_dou8vec_minmax+0x206/0x220 > > > > read: ipv6_flowlabel_opt+0x129/0xd20 > > > > do_ipv6_setsockopt+0x873/0x2220 > > > > udpv6_setsockopt+0x21/0x40 > > > > > > > > Fixes: 6444f72b4b74 ("ipv6: add flowlabel_consistency sysctl") > > > > Fixes: 82a584b7cd36 ("ipv6: Flow label state ranges") > > > > Cc: stable@vger.kernel.org > > > > Signed-off-by: Runyu Xiao > > > > --- > > > > net/ipv6/ip6_flowlabel.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >A > > > > diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c > > > > index b1ccdf0dc646..1ab5ad0dcf24 100644 > > > > --- a/net/ipv6/ip6_flowlabel.c > > > > +++ b/net/ipv6/ip6_flowlabel.c > > > > @@ -620,7 +620,7 @@ static int ipv6_flowlabel_get(struct sock *sk, = struct in6_flowlabel_req *freq, > > > > int err; > > > > > > > > if (freq->flr_flags & IPV6_FL_F_REFLECT) { > > > > - if (net->ipv6.sysctl.flowlabel_consistency) { > > > > + if (READ_ONCE(net->ipv6.sysctl.flowlabel_consistency)= ) { =20 > > > > > > That can't actually fix anything. =20 > >=20 > > It fixes a KCSAN splat. > >=20 > > If you think you can fix KCSAN instead, please do so. >=20 > It is a false positive. It's not. > (Which I think you also said in a different email. I guess you meant this one ? https://lore.kernel.org/netdev/20260601074201.1186061-1-runyu.xiao@seu.edu.= cn/ This is different because, in addition to Eric's comment, IPv6 address is 128-bit and data-race is inevitable without locking unless CPU supports native 128-bit read/write; we already do load/store-tearing of 128bit with u32/u64.