[syzbot] [wireguard?] KCSAN: data-race in wg_socket_send_skb_to_peer / wg_socket_send_skb_to_peer (9)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 9215e74f228f Merge tag 'block-7.1-20260529' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10465ef2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f571f22917457cd8
dashboard link: https://syzkaller.appspot.com/bug?extid=9ca7674fa7521a3f1bc2
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/1ddf3069118d/disk-9215e74f.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0913e4ffbdb8/vmlinux-9215e74f.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3fe3943ae796/bzImage-9215e74f.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9ca767...@syzkaller.appspotmail.com

==================================================================
BUG: KCSAN: data-race in wg_socket_send_skb_to_peer / wg_socket_send_skb_to_peer

read-write to 0xffff88811af99028 of 8 bytes by task 310 on cpu 1:
wg_socket_send_skb_to_peer+0xe8/0x130 drivers/net/wireguard/socket.c:182
wg_socket_send_buffer_to_peer+0xf1/0x120 drivers/net/wireguard/socket.c:199
wg_packet_send_handshake_initiation drivers/net/wireguard/send.c:40 [inline]
wg_packet_handshake_send_worker+0x10d/0x160 drivers/net/wireguard/send.c:51
process_one_work kernel/workqueue.c:3314 [inline]
process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3397
worker_thread+0x58a/0x780 kernel/workqueue.c:3478
kthread+0x22a/0x280 kernel/kthread.c:436
ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

read-write to 0xffff88811af99028 of 8 bytes by task 15360 on cpu 0:
wg_socket_send_skb_to_peer+0xe8/0x130 drivers/net/wireguard/socket.c:182
wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline]
wg_packet_tx_worker+0x12d/0x330 drivers/net/wireguard/send.c:276
process_one_work kernel/workqueue.c:3314 [inline]
process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3397
worker_thread+0x58a/0x780 kernel/workqueue.c:3478
kthread+0x22a/0x280 kernel/kthread.c:436
ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

value changed: 0x0000000000000a2c -> 0x0000000000000ac0

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 15360 Comm: kworker/0:2 Tainted: G W syzkaller #0 PREEMPT(lazy)
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Workqueue: wg-crypt-wg2 wg_packet_tx_worker
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Rafael Passos]

Hi,

I started investigating this KCSAN warning by syzbot, and would like to
ask a few questions.

I tracked the change to this counter increment in `wg_socket_send_skb_to_peer`

+++ b/drivers/net/wireguard/socket.c
@@ -179,7 +179,8 @@ int wg_socket_send_skb_to_peer(struct wg_peer *peer, struct sk_buff *skb, u8 ds)
else
dev_kfree_skb(skb);
if (likely(!ret))
-> peer->tx_bytes += skb_len; <- protected by a read_lock_bh only
read_unlock_bh(&peer->endpoint_lock);

It is protected by the read-part of a rwlock.
However, if the stack trace makes sense, this `wg_socket_send_skb_to_peer`
is being called after a handshake (wg_packet_send_handshake_initiation) and
a send worker call (wg_packet_tx_worker).

Does this make sense ? Are such calls possible to really hapen outside of fuzzing ?

Out of curiosity, I changed `tx_bytes` and `rx_bytes` from u64 to atomic64_t
in peer.h, and also the r/w ops in netlink.c, receive.c and socket.c files.
I ran the wireguard kselftest suite with and without this patch, and it
worked fine. Iperf results seem sine (on amd64).
I'm not sure if this should be the solution, or if this is even a real issue in the first place.

Any comments ?

Eager to learn.
Thanks,

Rafael Passos