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

On Tue, 8 Feb 2022 at 10:13, syzbot
[off-list ref] 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@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