[syzbot] KCSAN: data-race in wg_packet_handshake_receive_worker / wg_packet_rx_poll (3)

[Marco Elver]

On Tue, 8 Feb 2022 at 10:13, syzbot
<syzbot+ed414b05fe54c96947f8 at syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    455e73a07f6e Merge tag 'clk-for-linus' of git://git.kernel..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=131009feb00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e1f9a6122410716
> dashboard link: https://syzkaller.appspot.com/bug?extid=ed414b05fe54c96947f8
> compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ed414b05fe54c96947f8 at syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KCSAN: data-race in wg_packet_handshake_receive_worker / wg_packet_rx_poll
>
> read to 0xffff88813238a9e0 of 8 bytes by interrupt on cpu 1:
>  update_rx_stats drivers/net/wireguard/receive.c:28 [inline]
>  wg_packet_consume_data_done drivers/net/wireguard/receive.c:365 [inline]
>  wg_packet_rx_poll+0xf6b/0x11f0 drivers/net/wireguard/receive.c:481
>  __napi_poll+0x65/0x3f0 net/core/dev.c:6365
>  napi_poll net/core/dev.c:6432 [inline]
>  net_rx_action+0x29e/0x650 net/core/dev.c:6519
>  __do_softirq+0x158/0x2de kernel/softirq.c:558
>  do_softirq+0xb1/0xf0 kernel/softirq.c:459
>  __local_bh_enable_ip+0x68/0x70 kernel/softirq.c:383
>  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
>  _raw_spin_unlock_bh+0x33/0x40 kernel/locking/spinlock.c:210
>  spin_unlock_bh include/linux/spinlock.h:394 [inline]
>  ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline]
>  wg_packet_decrypt_worker+0x73c/0x780 drivers/net/wireguard/receive.c:506
>  process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
>  worker_thread+0x616/0xa70 kernel/workqueue.c:2454
>  kthread+0x2c7/0x2e0 kernel/kthread.c:327
>  ret_from_fork+0x1f/0x30
>
> write to 0xffff88813238a9e0 of 8 bytes by task 5035 on cpu 0:
>  update_rx_stats drivers/net/wireguard/receive.c:28 [inline]
>  wg_receive_handshake_packet drivers/net/wireguard/receive.c:205 [inline]
>  wg_packet_handshake_receive_worker+0x54a/0x6e0 drivers/net/wireguard/receive.c:220
>  process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
>  worker_thread+0x616/0xa70 kernel/workqueue.c:2454
>  kthread+0x2c7/0x2e0 kernel/kthread.c:327
>  ret_from_fork+0x1f/0x30
>
> value changed: 0x0000000000000aa8 -> 0x0000000000000ac8

Hi Jason,

For stats data races, in the majority of cases if the semantics is
"approximate" no harm is done, so the usual resolution is to mark them
intentionally racy with data_race() [1].

I've released these for completeness, but I can also skip them in
future. However, marking them appropriately helps because when all
intentionally racy accesses are marked, only "bad races" will be left,
and we can do less pre-moderation.

Thanks,
-- Marco

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt