Re: [PATCH net] ipv6: use READ_ONCE() in ipv6_flowlabel_get()

From: Eric Dumazet

Date: Sun May 31 2026 - 14:05:47 EST


On Sun, May 31, 2026 at 8:40 AM Runyu Xiao <runyu.xiao@xxxxxxxxxx> wrote:
>
> 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 checks
> run in the live IPV6_FLOWLABEL_MGR path, so lockless plain reads leave
> KCSAN-visible data races and can make the policy checks observe stale 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 repeatedly
> 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 scanning
> lockless IPv6 sysctl readers, then manually audited on Linux v6.18.21.
> The IPV6_FLOWLABEL_MGR paths were runtime-reproduced with QEMU/KCSAN by
> concurrently flipping the two sysctls while TCP reflect and UDP
> state-ranges setsockopt actors exercised ipv6_flowlabel_get(). KCSAN
> 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 reproducer
> 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 remaining
> 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
>

Please cut the verbosity, we do not need to copy/paste fifty lines
just to explain the obvious.

I hope you understand there is no serious bug here, KCSAN is a
debugging feature, not a production one.

One or two lines should be enough, you can take a look at
f062e8e25102324364aada61b8283356235bc3c1 ("ipv6: annotate data-races
in net/ipv6/route.c")

Also Fixes: tags are going to trigger extra work for many stable
teams, for no reason.