Re: [BUG REPORT] KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg

[Jiayuan Chen]

On 6/18/26 3:28 PM, xietangxin wrote:
> Hi all,
>
> We detected a data-race with syzkaller on master branch (commit 95e56f0f293e).
>
> The data-race occurs on `sk->sk_v6_daddr`. When a UDP socket is already in
> the ESTABLISHED state, calling sendmsg() with read `sk->sk_v6_daddr`.
> Concurrently, another thread call connect() on the same UDP socket to update
> the remote address, which writes to `sk->sk_v6_daddr`.
>
> Should we implement READ_ONCE/WRITE_ONCE helpers for `sk->sk_v6_daddr`
> to prevent torn reads? Or acquire the socket lock inside udpv6_sendmsg()
> to serialize with connect()?
>
> # KCSAN Report
> BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg
> read to 0xffff0000084dbc38 of 8 bytes by task 16916 on cpu 2:
>   udpv6_sendmsg+0x1264/0x1a20 (/include/net/ipv6.h:593 net/ipv6/udp.c:1579)
>   inet6_sendmsg+0x80/0xc0
>   __sock_sendmsg+0xb0/0x138
>   ____sys_sendmsg+0x41c/0x4f8
>   ___sys_sendmsg+0xcc/0x150
>   __sys_sendmsg+0xe8/0x190
>   __arm64_sys_sendmsg+0x58/0x78
>   invoke_syscall+0x84/0x218
>   el0_svc_common.constprop.0+0x1a4/0x1f8
>   do_el0_svc+0x3c/0x58
>   el0_svc+0x38/0x100
>   el0t_64_sync_handler+0xa0/0xe8
>   el0t_64_sync+0x190/0x198
>
> write to 0xffff0000084dbc38 of 16 bytes by task 16901 on cpu 1:
>   __ip6_datagram_connect+0x348/0x888 (/net/ipv6/datagram.c:247)
>   udpv6_connect+0x48/0x178
>   inet_dgram_connect+0xe0/0x1e0
>   __sys_connect_file+0xd4/0x128
>   __sys_connect+0xf0/0x130
>   __arm64_sys_connect+0x54/0x78
>   invoke_syscall+0x84/0x218
>   el0_svc_common.constprop.0+0x1a4/0x1f8
>   do_el0_svc+0x3c/0x58
>   el0_svc+0x38/0x100
>   el0t_64_sync_handler+0xa0/0xe8
>   el0t_64_sync+0x190/0x198
>
> # Syzkaller Reproducer
> r0 = bpf$PROG_LOAD(0x5, &(0x7f00000001c0)={0x6, 0x4, &(0x7f0000000100)=ANY=[@ANYBLOB="18000000000000000000000000000000070000000200000095"], &(0x7f0000000040)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x9, '\x00', 0x0, @xdp=0x25, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3}, 0x94)
> bpf$BPF_PROG_TEST_RUN(0xa, &(0x7f00000002c0)={r0, 0x0, 0xe, 0x0, &(0x7f00000005c0)="d9d96e34a80e31f03a049a9e0000", 0x0, 0xb4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x39}, 0x50) (async, rerun: 32)
> r1 = socket$inet6(0xa, 0x2, 0x0) (rerun: 32)
> connect$inet6(r1, &(0x7f0000000040)={0xa, 0x4e23, 0x100200a, @loopback, 0x7f}, 0x1c) (async, rerun: 32)
> sendmsg$inet6(r1, &(0x7f00000002c0)={&(0x7f0000000140)={0xa, 0x4e22, 0x4, @remote, 0x2}, 0x1c, 0x0}, 0x4000001) (rerun: 32)


Already exist in syzbot with 11 similar reports.

https://syzkaller.appspot.com/bug?id=e3ef1f59aa88bf20425f0726337b0f6931416ff8

maybe data_race annotation should be used.