From syzbot+6ba34f16b98fe40daef1 at syzkaller.appspotmail.com Tue Feb 8 08:32:20 2022 From: syzbot+6ba34f16b98fe40daef1 at syzkaller.appspotmail.com (syzbot) Date: Tue, 08 Feb 2022 00:32:20 -0800 Subject: [syzbot] KCSAN: data-race in wg_packet_send_staged_packets / wg_packet_send_staged_packets (3) Message-ID: <0000000000003aafee05d77d8e55@google.com> Hello, syzbot found the following issue on: HEAD commit: 2ade8eef993c Merge tag 'ata-5.17-rc4' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c03872700000 kernel config: https://syzkaller.appspot.com/x/.config?x=1dcc3374da7c1f7c dashboard link: https://syzkaller.appspot.com/bug?extid=6ba34f16b98fe40daef1 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+6ba34f16b98fe40daef1 at syzkaller.appspotmail.com ================================================================== BUG: KCSAN: data-race in wg_packet_send_staged_packets / wg_packet_send_staged_packets read to 0xffff888133f5eac8 of 4 bytes by interrupt on cpu 0: wg_cpumask_next_online drivers/net/wireguard/queueing.h:129 [inline] wg_queue_enqueue_per_device_and_peer drivers/net/wireguard/queueing.h:176 [inline] wg_packet_create_data drivers/net/wireguard/send.c:320 [inline] wg_packet_send_staged_packets+0x41a/0x800 drivers/net/wireguard/send.c:387 wg_packet_send_keepalive+0xfc/0x110 drivers/net/wireguard/send.c:239 wg_expired_send_persistent_keepalive+0x38/0x50 drivers/net/wireguard/timers.c:141 call_timer_fn+0x2e/0x240 kernel/time/timer.c:1421 expire_timers+0x116/0x240 kernel/time/timer.c:1466 __run_timers+0x368/0x410 kernel/time/timer.c:1734 run_timer_softirq+0x2e/0x60 kernel/time/timer.c:1747 __do_softirq+0x158/0x2de kernel/softirq.c:558 __irq_exit_rcu kernel/softirq.c:637 [inline] irq_exit_rcu+0x37/0x70 kernel/softirq.c:649 sysvec_apic_timer_interrupt+0x8d/0xb0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 __x64_sys_clock_nanosleep+0x54/0x60 kernel/time/posix-timers.c:1245 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae write to 0xffff888133f5eac8 of 4 bytes by interrupt on cpu 1: wg_cpumask_next_online drivers/net/wireguard/queueing.h:133 [inline] wg_queue_enqueue_per_device_and_peer drivers/net/wireguard/queueing.h:176 [inline] wg_packet_create_data drivers/net/wireguard/send.c:320 [inline] wg_packet_send_staged_packets+0x455/0x800 drivers/net/wireguard/send.c:387 wg_packet_send_keepalive+0xfc/0x110 drivers/net/wireguard/send.c:239 wg_expired_send_persistent_keepalive+0x38/0x50 drivers/net/wireguard/timers.c:141 call_timer_fn+0x2e/0x240 kernel/time/timer.c:1421 expire_timers+0x116/0x240 kernel/time/timer.c:1466 __run_timers+0x368/0x410 kernel/time/timer.c:1734 run_timer_softirq+0x2e/0x60 kernel/time/timer.c:1747 __do_softirq+0x158/0x2de kernel/softirq.c:558 __irq_exit_rcu kernel/softirq.c:637 [inline] irq_exit_rcu+0x37/0x70 kernel/softirq.c:649 sysvec_apic_timer_interrupt+0x8d/0xb0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 is_atomic kernel/kcsan/core.c:262 [inline] should_watch kernel/kcsan/core.c:275 [inline] check_access kernel/kcsan/core.c:741 [inline] __tsan_read2+0x13e/0x180 kernel/kcsan/core.c:1012 tlb_flush_pte_range include/asm-generic/tlb.h:524 [inline] zap_pte_range+0x559/0x10e0 mm/memory.c:1366 zap_pmd_range mm/memory.c:1490 [inline] zap_pud_range mm/memory.c:1519 [inline] zap_p4d_range mm/memory.c:1540 [inline] unmap_page_range+0x2dc/0x3d0 mm/memory.c:1561 unmap_single_vma+0x157/0x210 mm/memory.c:1606 unmap_vmas+0xd0/0x180 mm/memory.c:1638 exit_mmap+0x261/0x4b0 mm/mmap.c:3178 __mmput+0x27/0x1b0 kernel/fork.c:1114 mmput+0x3d/0x50 kernel/fork.c:1135 exit_mm+0xdb/0x170 kernel/exit.c:507 do_exit+0x569/0x16a0 kernel/exit.c:793 do_group_exit+0xa5/0x160 kernel/exit.c:935 get_signal+0x8cf/0x15d0 kernel/signal.c:2862 arch_do_signal_or_restart+0x8c/0x2e0 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x113/0x190 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:300 do_syscall_64+0x50/0xd0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000001 -> 0x00000000 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 21549 Comm: syz-executor.4 Not tainted 5.17.0-rc3-syzkaller-00013-g2ade8eef993c-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ================================================================== sd 0:0:1:0: [sda] tag#3016 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3016 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3016 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3016 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3016 CDB[20]: ba sd 0:0:1:0: [sda] tag#3023 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3023 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3023 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3023 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3023 CDB[20]: ba sd 0:0:1:0: [sda] tag#3025 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3025 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3025 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3025 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3025 CDB[20]: ba sd 0:0:1:0: [sda] tag#3026 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3026 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3026 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3026 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3026 CDB[20]: ba sd 0:0:1:0: [sda] tag#3027 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3027 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3027 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3027 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3027 CDB[20]: ba sd 0:0:1:0: [sda] tag#3029 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3029 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3029 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3029 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3029 CDB[20]: ba sd 0:0:1:0: [sda] tag#3056 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3056 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3056 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3056 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3056 CDB[20]: ba sd 0:0:1:0: [sda] tag#3057 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3057 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3057 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3057 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3057 CDB[20]: ba sd 0:0:1:0: [sda] tag#3059 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3059 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3059 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3059 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3059 CDB[20]: ba sd 0:0:1:0: [sda] tag#3060 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3060 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3060 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3060 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3060 CDB[20]: ba sd 0:0:1:0: [sda] tag#3061 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3061 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3061 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3061 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3061 CDB[20]: ba sd 0:0:1:0: [sda] tag#3062 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3062 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3062 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3062 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3062 CDB[20]: ba sd 0:0:1:0: [sda] tag#3063 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=0s sd 0:0:1:0: [sda] tag#3063 CDB: opcode=0xe5 (vendor) sd 0:0:1:0: [sda] tag#3063 CDB[00]: e5 f4 32 73 2f 4e 09 6d 26 e2 c7 35 d1 35 12 1c sd 0:0:1:0: [sda] tag#3063 CDB[10]: 92 1b da 40 b8 58 5b a8 d4 7d 34 f3 90 4c f1 2d sd 0:0:1:0: [sda] tag#3063 CDB[20]: ba --- 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 syzkaller at googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. From syzbot+d1de830e4ecdaac83d89 at syzkaller.appspotmail.com Tue Feb 8 08:33:29 2022 From: syzbot+d1de830e4ecdaac83d89 at syzkaller.appspotmail.com (syzbot) Date: Tue, 08 Feb 2022 00:33:29 -0800 Subject: [syzbot] KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll (2) Message-ID: <0000000000005733c005d77d9215@google.com> Hello, syzbot found the following issue on: HEAD commit: 2ade8eef993c Merge tag 'ata-5.17-rc4' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=112ef758700000 kernel config: https://syzkaller.appspot.com/x/.config?x=1dcc3374da7c1f7c dashboard link: https://syzkaller.appspot.com/bug?extid=d1de830e4ecdaac83d89 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+d1de830e4ecdaac83d89 at syzkaller.appspotmail.com ================================================================== BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888127d03888 of 8 bytes by interrupt on cpu 1: counter_validate drivers/net/wireguard/receive.c:328 [inline] wg_packet_rx_poll+0x436/0x11f0 drivers/net/wireguard/receive.c:468 __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+0x1bf/0x1e0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 read to 0xffff888127d03888 of 8 bytes by task 1912 on cpu 0: decrypt_packet drivers/net/wireguard/receive.c:259 [inline] wg_packet_decrypt_worker+0x23a/0x780 drivers/net/wireguard/receive.c:508 process_one_work+0x3f6/0x960 kernel/workqueue.c:2307 worker_thread+0x616/0xa70 kernel/workqueue.c:2454 kthread+0x1bf/0x1e0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 value changed: 0x0000000000000bb9 -> 0x0000000000000bba Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 1912 Comm: kworker/0:3 Not tainted 5.17.0-rc3-syzkaller-00013-g2ade8eef993c-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: wg-crypt-wg1 wg_packet_decrypt_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 syzkaller at googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. From syzbot+ed414b05fe54c96947f8 at syzkaller.appspotmail.com Tue Feb 8 09:13:22 2022 From: syzbot+ed414b05fe54c96947f8 at syzkaller.appspotmail.com (syzbot) Date: Tue, 08 Feb 2022 01:13:22 -0800 Subject: [syzbot] KCSAN: data-race in wg_packet_handshake_receive_worker / wg_packet_rx_poll (3) Message-ID: <000000000000f5988505d77e20e4@google.com> 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 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5035 Comm: kworker/0:60 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: wg-kex-wg2 wg_packet_handshake_receive_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 syzkaller at googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. From syzbot+5d8276c437d9827c1fbf at syzkaller.appspotmail.com Tue Feb 8 09:13:22 2022 From: syzbot+5d8276c437d9827c1fbf at syzkaller.appspotmail.com (syzbot) Date: Tue, 08 Feb 2022 01:13:22 -0800 Subject: [syzbot] KCSAN: data-race in dev_get_tstats64 / wg_packet_rx_poll (3) Message-ID: <000000000000f8dc8805d77e202f@google.com> Hello, syzbot found the following issue on: HEAD commit: 79e06c4c4950 Merge tag 'for-linus' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1642e837b00000 kernel config: https://syzkaller.appspot.com/x/.config?x=d443ab22c440893a dashboard link: https://syzkaller.appspot.com/bug?extid=5d8276c437d9827c1fbf 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+5d8276c437d9827c1fbf at syzkaller.appspotmail.com ================================================================== BUG: KCSAN: data-race in dev_get_tstats64 / wg_packet_rx_poll write to 0xffffe8ffffc39fe0 of 8 bytes by interrupt on cpu 0: update_rx_stats drivers/net/wireguard/receive.c:26 [inline] wg_packet_consume_data_done drivers/net/wireguard/receive.c:365 [inline] wg_packet_rx_poll+0xf37/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 read to 0xffffe8ffffc39fe0 of 8 bytes by task 7601 on cpu 1: dev_fetch_sw_netstats net/core/dev.c:10050 [inline] dev_get_tstats64+0x117/0x1e0 net/core/dev.c:10075 dev_get_stats+0x65/0x180 net/core/dev.c:10017 rtnl_fill_stats+0x45/0x320 net/core/rtnetlink.c:1203 rtnl_fill_ifinfo+0xf16/0x25b0 net/core/rtnetlink.c:1776 rtmsg_ifinfo_build_skb+0xa8/0x130 net/core/rtnetlink.c:3833 rtmsg_ifinfo_event net/core/rtnetlink.c:3865 [inline] rtmsg_ifinfo+0x58/0xc0 net/core/rtnetlink.c:3874 __dev_notify_flags+0x63/0x3b0 net/core/dev.c:8173 dev_change_flags+0xa2/0xc0 net/core/dev.c:8215 do_setlink+0x820/0x2500 net/core/rtnetlink.c:2729 __rtnl_newlink net/core/rtnetlink.c:3412 [inline] rtnl_newlink+0xfad/0x13b0 net/core/rtnetlink.c:3527 rtnetlink_rcv_msg+0x745/0x7e0 net/core/rtnetlink.c:5592 netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2494 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5610 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x602/0x6d0 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x728/0x850 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] __sys_sendto+0x21e/0x2c0 net/socket.c:2040 __do_sys_sendto net/socket.c:2052 [inline] __se_sys_sendto net/socket.c:2048 [inline] __x64_sys_sendto+0x74/0x90 net/socket.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000000000000001 -> 0x0000000000000002 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 7601 Comm: syz-executor.0 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ================================================================== --- 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 syzkaller at googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. From elver at google.com Tue Feb 8 09:22:55 2022 From: elver at google.com (Marco Elver) Date: Tue, 8 Feb 2022 10:22:55 +0100 Subject: [syzbot] KCSAN: data-race in wg_packet_handshake_receive_worker / wg_packet_rx_poll (3) In-Reply-To: <000000000000f5988505d77e20e4@google.com> References: <000000000000f5988505d77e20e4@google.com> Message-ID: On Tue, 8 Feb 2022 at 10:13, syzbot 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 From michal.murin at jamf.com Wed Feb 9 10:57:58 2022 From: michal.murin at jamf.com (Michal Murin) Date: Wed, 9 Feb 2022 11:57:58 +0100 Subject: [PATCH] tunnel: fixed BadConfigExceptionTest Message-ID: <20220209105758.22038-1-michal.murin@jamf.com> Fixed the test by changing the DNS to a string with an invalid char in the `invalid-value.conf` test configuration file. Signed-off-by: Michal Murin --- tunnel/src/test/resources/invalid-value.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tunnel/src/test/resources/invalid-value.conf b/tunnel/src/test/resources/invalid-value.conf index 2889111..6a1e3b6 100644 --- a/tunnel/src/test/resources/invalid-value.conf +++ b/tunnel/src/test/resources/invalid-value.conf @@ -1,6 +1,6 @@ [Interface] Address = 192.0.2.2/32,2001:db8:ffff:ffff:ffff:ffff:ffff:ffff/128 -DNS = 192.0.2.0,yes +DNS = 192.0.2.0,invalid_value PrivateKey = TFlmmEUC7V7VtiDYLKsbP5rySTKLIZq1yn8lMqK83wo= [Peer] AllowedIPs = 0.0.0.0/0, ::0/0 -- 2.30.1 (Apple Git-130) From Jason at zx2c4.com Wed Feb 9 11:02:19 2022 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 9 Feb 2022 12:02:19 +0100 Subject: [PATCH] tunnel: fixed BadConfigExceptionTest In-Reply-To: <20220209105758.22038-1-michal.murin@jamf.com> References: <20220209105758.22038-1-michal.murin@jamf.com> Message-ID: Applied, thanks. From markus at activezone.de Thu Feb 10 00:21:07 2022 From: markus at activezone.de (markus at activezone.de) Date: Thu, 10 Feb 2022 01:21:07 +0100 Subject: Feature Request :: Configuration-Option "ospf = yes|no" on Multi-Peer-Interfaces In-Reply-To: References: <20211208173205.zajfvg6zvi4g5kln@linutronix.de> Message-ID: <23d0b3c7-ff03-981e-3d24-c81273037757@mitteilung.com> Hi! Basically, I understood that WireGuard uses a kind of packet forwarding (routing) via "allowed-ips". Since the beginning I have always used a dedicated interface with "..., 224.0.0.5/32" for each peer and it works. However, I believe that an option is missing in order to allow a 224.0.0.5 per peer in a multi-peer interface, that it is multicast traffic, it shouldn't be a problem, right?! Or just an option "ospf = yes|no" with which it is decided whether OSPF is transmitted in a peer or not. This would allow even greater flexibility between peer nodes with regard to dynamic routing. opinions on this? Best regards, Markus From brian at kuehn.se Wed Feb 9 13:59:18 2022 From: brian at kuehn.se (brian at kuehn.se) Date: Wed, 9 Feb 2022 14:59:18 +0100 Subject: Installer failed to install on Win 11 Message-ID: <00b501d81dbd$3b2514e0$b16f3ea0$@kuehn.se> Hello all! I?ve been trying to install the Windows Client on my Win 11 machine. To no avail. No I can?t change over to Linux on this machine. ? The installer downloads fine. When started it just sits and waits for something. After a while, don?t know how long exactly, but maybe around 10 minutes a message shows up and says the installer has stopped responding. I tried a retry, but same procedure. The .msi file downloads fine. When started, it says wait until Windows configures the install. Then after like 10 minutes, a message pops up saying the server isn?t responding. I tried a retry, but same as before. I am a programmer, but Go isn?t something I?ve even played with, and I am totally new to this area of computing. I?ll probably open a VM and in Linux hook up this way until the client will install. Greetings, Brian Kuehn From alexisgandroid at gmail.com Sat Feb 12 02:20:39 2022 From: alexisgandroid at gmail.com (Alexis gg) Date: Sat, 12 Feb 2022 11:20:39 +0900 Subject: reresolve-dns: use $EPOCHSECONDS instead of $(date +%s) Message-ID: This commit breaks everything on older OSes (esp. Centos 7): https://git.zx2c4.com/wireguard-tools/commit/?id=1fd95708391088742c139010cc6b821add941dec There is no check on the bash's version, the built-in variable $EPOCHSECONDS is available only from bash 5. https://lists.gnu.org/archive/html/info-gnu/2019-01/msg00010.html This isn't an improvement, $(date +%s) is stable from much older versions and will stay stable in future bash versions. From brian at kuehn.se Mon Feb 14 17:55:04 2022 From: brian at kuehn.se (Brian Kuehn) Date: Mon, 14 Feb 2022 18:55:04 +0100 Subject: Installer failed to install on Win 11 In-Reply-To: <00b501d81dbd$3b2514e0$b16f3ea0$@kuehn.se> References: <00b501d81dbd$3b2514e0$b16f3ea0$@kuehn.se> Message-ID: Hello all! I?ve since this last message been able to install Wireguard. I?ve connected to my server and everything thing works perfectly. In the Device Manager I have 3 Unknown devices, all seemingly connected to Wireguard. It wasn?t until I deactivated these unknown devices that everything kicked in motion. Upon further investigation I found 2 network devices showing Wireguard affiliation. I have to open a windows terminal with admin access to open a Wireguard session that activates. The thing I am wondering about is, why didn?t the options to run as admin work in the first place? I have checked my Win 11 installation and there is nothing outstanding nor nothing else strange. Any insights would be great. Also how to get rid of the unknown devices would also be helpful. Greetings, Brian Kuehn Skickat fr?n min iPhone > 14 feb. 2022 kl. 15:05 skrev brian at kuehn.se: > > ?Hello all! > > I?ve been trying to install the Windows Client on my Win 11 machine. To no avail. > > No I can?t change over to Linux on this machine. ? > > The installer downloads fine. When started it just sits and waits for something. After a while, don?t know how long exactly, but maybe around 10 minutes a message shows up and says the installer has stopped responding. I tried a retry, but same procedure. > > The .msi file downloads fine. When started, it says wait until Windows configures the install. Then after like 10 minutes, a message pops up saying the server isn?t responding. I tried a retry, but same as before. > > I am a programmer, but Go isn?t something I?ve even played with, and I am totally new to this area of computing. I?ll probably open a VM and in Linux hook up this way until the client will install. > > Greetings, > > Brian Kuehn > > From peljasz at yahoo.co.uk Wed Feb 16 14:43:23 2022 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 16 Feb 2022 14:43:23 +0000 Subject: firewall / port forward - ? References: <59b73202-4c8c-2ff2-fca8-209cc3f3ac54.ref@yahoo.co.uk> Message-ID: <59b73202-4c8c-2ff2-fca8-209cc3f3ac54@yahoo.co.uk> Hi guys. I'm still new to wireguard and still not an expert on network stack so I struggle with something what might be trivial. A roadwarrior when connected to the server sees a forward-port on server's internal network as 'closed': 10.3.9.10 -> 10.3.9.1 10.3.1.1 (port forward) => 10.8.9.1 (a dummy iface, still server) but rest of 10.3.1.0/24 sees that forwarded port - as I expected - as 'open' If that same server port is not forwarded ("stays" on 10.3.1.1) then that roadwarrior sees the port as 'open' I've fiddled with firewall all I could so I think it's not in there - thus hoping expert(s) can help me wrap my head around it. many thanks, L. From laura.zelenku at wandera.com Wed Feb 16 15:30:08 2022 From: laura.zelenku at wandera.com (Laura Zelenku) Date: Wed, 16 Feb 2022 16:30:08 +0100 Subject: [PATCH] Lower log level of 'invalid state for keypair derivation' Message-ID: Error is caused by multiple handshakes processing in the same time for the same peer. Invalid state is not harmful for a peer and the other/faster handshake wins. Signed-off-by: Laura Zelenku --- device/receive.go | 3 +-- device/send.go | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/device/receive.go b/device/receive.go index cc34498..25fb7d9 100644 --- a/device/receive.go +++ b/device/receive.go @@ -379,9 +379,8 @@ func (device *Device) RoutineHandshake(id int) { // derive keypair err = peer.BeginSymmetricSession() - if err != nil { - device.log.Errorf("%v - Failed to derive keypair: %v", peer, err) + device.log.Verbosef("%v - Failed to derive keypair: %v", peer, err) goto skip } diff --git a/device/send.go b/device/send.go index 0a7135f..9598bee 100644 --- a/device/send.go +++ b/device/send.go @@ -156,7 +156,7 @@ func (peer *Peer) SendHandshakeResponse() error { err = peer.BeginSymmetricSession() if err != nil { - peer.device.log.Errorf("%v - Failed to derive keypair: %v", peer, err) + peer.device.log.Verbosef("%v - Failed to derive keypair: %v", peer, err) return err } -- 2.30.1 (Apple Git-130) -- *IMPORTANT NOTICE*: This email, its attachments and any rights attaching hereto are confidential and intended exclusively for the person to whom the email is addressed. If you are not the intended recipient, do not read, copy, disclose or use the contents in any way. Wandera accepts no liability for any loss, damage or consequence resulting directly or indirectly from the use of this email and attachments. From laura.zelenku at wandera.com Fri Feb 18 10:08:27 2022 From: laura.zelenku at wandera.com (Laura Zelenku) Date: Fri, 18 Feb 2022 11:08:27 +0100 Subject: [PATCH] Lower log level on handshake race condition Message-ID: This issue is caused by "handshake initiation must be consumed first" error. It is quite weird because this is happening during responding on received Handshake initiation message but probably status of handshake is not set correctly in single thread for single peer. Signed-off-by: Laura Zelenku --- device/send.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/device/send.go b/device/send.go index 0a7135f..0f0905a 100644 --- a/device/send.go +++ b/device/send.go @@ -144,7 +144,7 @@ func (peer *Peer) SendHandshakeResponse() error { response, err := peer.device.CreateMessageResponse(peer) if err != nil { - peer.device.log.Errorf("%v - Failed to create response message: %v", peer, err) + peer.device.log.Verbosef("%v - Failed to create response message: %v", peer, err) return err } -- 2.32.0 (Apple Git-132) -- *IMPORTANT NOTICE*: This email, its attachments and any rights attaching hereto are confidential and intended exclusively for the person to whom the email is addressed. If you are not the intended recipient, do not read, copy, disclose or use the contents in any way. Wandera accepts no liability for any loss, damage or consequence resulting directly or indirectly from the use of this email and attachments. From dheidler at suse.de Fri Feb 18 11:55:57 2022 From: dheidler at suse.de (Dominik Heidler) Date: Fri, 18 Feb 2022 12:55:57 +0100 Subject: [PATCH] wg-quick hatchet: Support systemd-resolved split-dns setup Message-ID: --- contrib/dns-hatchet/hatchet.bash | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/contrib/dns-hatchet/hatchet.bash b/contrib/dns-hatchet/hatchet.bash index bc4d090..30eb25b 100644 --- a/contrib/dns-hatchet/hatchet.bash +++ b/contrib/dns-hatchet/hatchet.bash @@ -5,7 +5,8 @@ set_dns() { { printf 'nameserver %s\n' "${DNS[@]}" [[ ${#DNS_SEARCH[@]} -eq 0 ]] || printf 'search %s\n' "${DNS_SEARCH[*]}" } | cmd resolvconf -a "$INTERFACE" -m 0 -x - else + # Don't ruin a proper split dns setup + elif [[ "$(readlink /etc/resolv.conf)" != "/run/systemd/resolve/stub-resolv.conf" ]] ; then echo "[#] mount \`${DNS[*]}' /etc/resolv.conf" >&2 [[ -e /etc/resolv.conf ]] || touch /etc/resolv.conf { cat <<-_EOF @@ -30,6 +31,15 @@ set_dns() { _EOF )" fi + # If systemd-resolved is installed, set the dns configuration there (as well). + # It might be used additionally (eg for containers) or even for the whole system. + # A teardown is not really needed as resolvectl detects the interface disappearing. + if resolvectl status >/dev/null 2>&1 ; then + cmd resolvectl dns "$INTERFACE" "${DNS[@]}" + # Prefix each domain with '~' which will tell resolvectl to use that domain + # for dns routing but not as a search domain + cmd resolvectl domain "$INTERFACE" "${DNS_SEARCH[*]/#/\~}" + fi HAVE_SET_DNS=1 } -- 2.35.1 From houmie at gmail.com Sat Feb 19 17:34:50 2022 From: houmie at gmail.com (Houman) Date: Sat, 19 Feb 2022 17:34:50 +0000 Subject: Is there a Delegate for the Wireguard status in PacketTunnelProvider (iOS) Message-ID: Hello, I wonder if there is a Delegate we could use in PacketTunnelProvider to observe the state of Wireguard VPN. For example OpenVPN has something like this: extension PacketTunnelProvider: OpenVPNAdapterDelegate { func openVPNAdapter(_ openVPNAdapter: OpenVPNAdapter, handleEvent event: OpenVPNAdapterEvent, message: String?) { switch event { case .connected: case .disconnected: case .reconnecting: default: break } } } Do we have this in Wireguard? I know it's possible to subscribe to this NEVPNStatusDidChange in the main app instead: override func viewDidLoad() { NotificationCenter.default.addObserver(self, selector: #selector(vpnStatusDidChange(_:)), name: NSNotification.Name.NEVPNStatusDidChange, object: nil) } But this doesn't work well for Third party VPNs that integrate over the NetworkExtension framework. Even though I have observed this once, I see multiple connected states being triggered, after connecting a single time to the VPN. @objc private func vpnStatusDidChange(_ notification: Notification) { let nevpnconn = notification.object as! NEVPNConnection let status = nevpnconn.status switch status { case NEVPNStatus.invalid: case NEVPNStatus.disconnected: case NEVPNStatus.connecting: case NEVPNStatus.connected: ... } Any suggestions please? Thanks, From s.devanath at gmail.com Mon Feb 21 18:10:18 2022 From: s.devanath at gmail.com (Devanath S) Date: Mon, 21 Feb 2022 10:10:18 -0800 Subject: Wireguard netstack client/server Message-ID: Hi, Was trying to understand the netstack related examples in wireguard-go/tun/netstack/examples/ Examples for netstack available in other distributions, all do createNIC using the fd of the network on the host-machine or likewise. So packets enter/leave netstack through those interfaces. With wireguard-go/tun/netstack/examples/ I dont see any interface created on the host machine, then how are the packets enter/leave netstack where wireguard devices are running? Plz advice. Regards, dev From rujbin at protonmail.com Sat Feb 19 01:23:51 2022 From: rujbin at protonmail.com (Rujbin) Date: Sat, 19 Feb 2022 01:23:51 +0000 Subject: WireGuard Windows should have default MTU of 1280. Message-ID: Hello, i am just confused. When i use default MTU the Performance on Windows is VERY poor. It is almost unuseable. It happens on multiple Windows devices. I started using MTU 1280 for a while, but why is it only Windows with that issue? First, the speed is limited to 100mbps maximum. Thats weird, when i use MTU 1280 i have 1gbps. https://i.imgur.com/ELGOWDQ.png This bug exists for a long time to me. I ran Wireguard on almost every provider, (i didnt check if it happens on Azure) but this bug exists on Hetzner, DigitalOcean, OVH. This is not normal. I am running the latest stable version of Wireguard Windows. Kernel module on servers and BoringTun. From tlhackque at yahoo.com Mon Feb 21 18:52:05 2022 From: tlhackque at yahoo.com (tlhackque) Date: Mon, 21 Feb 2022 13:52:05 -0500 Subject: WireGuard Windows should have default MTU of 1280. In-Reply-To: References: Message-ID: <3fea080f-9d01-6471-31e2-e14e39c02575@yahoo.com> On 18-Feb-22 20:23, Rujbin wrote: > Hello, > > i am just confused. When i use default MTU the Performance on Windows is VERY poor. It is almost unuseable. It happens on multiple Windows devices. I started using MTU 1280 for a while, but why is it only Windows with that issue? First, the speed is limited to 100mbps maximum. Thats weird, when i use MTU 1280 i have 1gbps. https://i.imgur.com/ELGOWDQ.png > > This bug exists for a long time to me. I ran Wireguard on almost every provider, (i didnt check if it happens on Azure) but this bug exists on Hetzner, DigitalOcean, OVH. This is not normal. I am running the latest stable version of Wireguard Windows. Kernel module on servers and BoringTun. The question is so vague that you're not going to get unconfused without doing more work. Sounds like a fragmentation issue.? Where can't be determined from the information given.? But if path MTU discovery is disabled/broken, that kind of slowdown isn't surprising. 1280 is the minimum MTU for IPv6.? (Path discovery is encouraged to use larger if possible.)? See RFC2460 section 5. Where are you setting the MTU?? On the physical IF, or the WireGuard IF? If the former, you want to increase by the size of the WG overhead. If your physical IF is IPv4, but you're tunneling IPv6 over WG - the minimum MTU for IPv4 is 512, so unless some MTU is set (and available for the complete route), WG packets will definitely fragment. In short, you need to provide more information (including a complete configuration, traceroutes with packet sizes, see if MTU discovery is blocked, ...), and do more work in order to get a useful answer. This includes the Windows question.? Is WG running on windows, or on some router?? IPv4?? How does this differ from the other devices?? What are they (IOS, Android, Linux, VMS, ZOS, ...)? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From mjt at tls.msk.ru Mon Feb 21 18:53:26 2022 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 21 Feb 2022 21:53:26 +0300 Subject: WireGuard Windows should have default MTU of 1280. In-Reply-To: References: Message-ID: 19.02.2022 04:23, Rujbin wrote: > Hello, > > i am just confused. When i use default MTU the Performance on Windows is VERY poor. It is almost unuseable. It happens on multiple Windows devices. I started using MTU 1280 for a while, but why is it only Windows with that issue? First, the speed is limited to 100mbps maximum. Thats weird, when i use MTU 1280 i have 1gbps. https://i.imgur.com/ELGOWDQ.png In our case with default MTU (of 1420 iirc), in-tunnel performance is near the direct pefrormance. When lowering MTU to 1280, the speed reduces a bit but not much (I guess due to larger overhead due to smaller packet size). > This bug exists for a long time to me. I ran Wireguard on almost every provider, (i didnt check if it happens on Azure) but this bug exists on Hetzner, DigitalOcean, OVH. This is not normal. I am running the latest stable version of Wireguard Windows. Kernel module on servers and BoringTun. I don't see a bug here. /mjt From mjt at tls.msk.ru Mon Feb 21 19:16:22 2022 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 21 Feb 2022 22:16:22 +0300 Subject: WireGuard Windows should have default MTU of 1280. In-Reply-To: References: Message-ID: <6ba013e9-05db-17bc-995b-11ef1f279c91@msgid.tls.msk.ru> 21.02.2022 22:11, Michael Adams wrote: > Throwing in my two cents: I was using MTU 1280 on Tinc a few years back, for IPv6 VPN support on Windows & Linux. It's good practice. Lemme guess. The OP is routing wg packets over IPv6? Can this be the problem here, because V6 has larger overhead so that 1420 is too large to fit into 1500 bytes together with IPv6 header? Speaking of the good practice - it really depends. /mjt From mjt at tls.msk.ru Mon Feb 21 19:18:48 2022 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 21 Feb 2022 22:18:48 +0300 Subject: WireGuard Windows should have default MTU of 1280. In-Reply-To: References: Message-ID: 21.02.2022 22:11, Michael Adams wrote: > Throwing in my two cents: I was using MTU 1280 on Tinc a few years back, for IPv6 VPN support on Windows & Linux. It's good practice. BTW, tinc is quite good these days at figuring the right pMTU. It fails only in case of completely broken network.. /mjt From rm at romanrm.net Mon Feb 21 19:57:10 2022 From: rm at romanrm.net (Roman Mamedov) Date: Tue, 22 Feb 2022 00:57:10 +0500 Subject: WireGuard Windows should have default MTU of 1280. In-Reply-To: <6ba013e9-05db-17bc-995b-11ef1f279c91@msgid.tls.msk.ru> References: <6ba013e9-05db-17bc-995b-11ef1f279c91@msgid.tls.msk.ru> Message-ID: <20220222005710.705a7023@nvm> On Mon, 21 Feb 2022 22:16:22 +0300 Michael Tokarev wrote: > 21.02.2022 22:11, Michael Adams wrote: > > Throwing in my two cents: I was using MTU 1280 on Tinc a few years back, for IPv6 VPN support on Windows & Linux. It's good practice. > > Lemme guess. The OP is routing wg packets over IPv6? Can this be > the problem here, because V6 has larger overhead so that 1420 is > too large to fit into 1500 bytes together with IPv6 header? 1420 is picked specifically so that it fits into a 1500 byte packet with IPv6. If you run WG exclusively over IPv4, you can use up to 1432. However, if your ISP uses, say, PPPoE or L2TP, you need to reduce these numbers accordingly, as the underlying interface will not have the full 1500 byte MTU. -- With respect, Roman From rm at romanrm.net Mon Feb 21 21:44:43 2022 From: rm at romanrm.net (Roman Mamedov) Date: Tue, 22 Feb 2022 02:44:43 +0500 Subject: WireGuard Windows should have default MTU of 1280. In-Reply-To: <20220222005710.705a7023@nvm> References: <6ba013e9-05db-17bc-995b-11ef1f279c91@msgid.tls.msk.ru> <20220222005710.705a7023@nvm> Message-ID: <20220222024443.1efe2c02@nvm> On Tue, 22 Feb 2022 00:57:10 +0500 Roman Mamedov wrote: > On Mon, 21 Feb 2022 22:16:22 +0300 > Michael Tokarev wrote: > > > 21.02.2022 22:11, Michael Adams wrote: > > > Throwing in my two cents: I was using MTU 1280 on Tinc a few years back, for IPv6 VPN support on Windows & Linux. It's good practice. > > > > Lemme guess. The OP is routing wg packets over IPv6? Can this be > > the problem here, because V6 has larger overhead so that 1420 is > > too large to fit into 1500 bytes together with IPv6 header? > > 1420 is picked specifically so that it fits into a 1500 byte packet with IPv6. > > If you run WG exclusively over IPv4, you can use up to 1432. Correction: 1440. https://www.mail-archive.com/wireguard at lists.zx2c4.com/msg01856.html I'm just used to subtracting 8 everywhere, because my ISP *does* use PPPoE. :) -- With respect, Roman From dave at natulte.net Wed Feb 23 05:21:15 2022 From: dave at natulte.net (David Anderson) Date: Tue, 22 Feb 2022 21:21:15 -0800 Subject: WireGuard Windows should have default MTU of 1280. In-Reply-To: <20220222024443.1efe2c02@nvm> References: <6ba013e9-05db-17bc-995b-11ef1f279c91@msgid.tls.msk.ru> <20220222005710.705a7023@nvm> <20220222024443.1efe2c02@nvm> Message-ID: FWIW, a variety of cloud providers have a leaky abstraction, where they expose an MTU slightly below 1500 to their VMs due to encapsulation they use internally, and not using jumbo frames for various reasons. For example, Google Compute Engine VMs have an MTU of 1460b before WireGuard. So, if you blindly set your MTU to "1500 minus exactly WireGuard overhead", it'll mysteriously break in those cloud environments (unless you get lucky with PMTUD saving the day, but I tend to assume it got broken by a misguided firewall). It's a common stumbling block I've seen many people hit when deploying WireGuard to cloudy environments that aren't AWS or on-premises systems (which tend to have well-behaved MTUs and jumbo frames on the wire, empirically). Unfortunately dropping the wg MTU all the way to 1280 can break stuff differently, for people running encapsulation _inside_ WireGuard, because then their inner packet size is smaller than the mandated minimum for IPv6. So, short of building OOB MTU discovery into WireGuard (a-la QUIC - a reasonably big complexity bump), there's no one size fits all default that'll make everyone happy, I fear. - Dave On Mon, Feb 21, 2022, at 13:44, Roman Mamedov wrote: > On Tue, 22 Feb 2022 00:57:10 +0500 > Roman Mamedov wrote: > > > On Mon, 21 Feb 2022 22:16:22 +0300 > > Michael Tokarev wrote: > > > > > 21.02.2022 22:11, Michael Adams wrote: > > > > Throwing in my two cents: I was using MTU 1280 on Tinc a few years back, for IPv6 VPN support on Windows & Linux. It's good practice. > > > > > > Lemme guess. The OP is routing wg packets over IPv6? Can this be > > > the problem here, because V6 has larger overhead so that 1420 is > > > too large to fit into 1500 bytes together with IPv6 header? > > > > 1420 is picked specifically so that it fits into a 1500 byte packet with IPv6. > > > > If you run WG exclusively over IPv4, you can use up to 1432. > > Correction: 1440. > > https://www.mail-archive.com/wireguard at lists.zx2c4.com/msg01856.html > > I'm just used to subtracting 8 everywhere, because my ISP *does* use PPPoE. :) > > -- > With respect, > Roman > From alessio.nossa+list at gmail.com Wed Feb 23 09:41:39 2022 From: alessio.nossa+list at gmail.com (Alessio Nossa) Date: Wed, 23 Feb 2022 10:41:39 +0100 Subject: [wireguard-apple] Merge of contributions Message-ID: Hello, A few weeks ago I pushed some changes to the wireguard-apple repository (an/shortcuts-integration branch [1]) and also created a pull request on GitHub [2] as indicated in the message returned by the server on git push. However, there was no sign of a review/merge. Is there anything I can do to speed up the process? Do you have an ETA for the next WireGuard iOS app update? I have tried my best to facilitate this, because I really need the Siri Shortcuts integration to be available and I don't want to distribute a custom version of the WireGuard iOS app just to add this integration. Thank you, Alessio Nossa [1] https://git.zx2c4.com/wireguard-apple/log/?h=an/shortcuts-integration [2] https://github.com/WireGuard/wireguard-apple/pull/8 From Jason at zx2c4.com Wed Feb 23 12:25:14 2022 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 23 Feb 2022 13:25:14 +0100 Subject: [wireguard-apple] Merge of contributions In-Reply-To: References: Message-ID: Hi Alessio, There's quite a bit of iOS/macOS backlog. But I'll get to it (or Roop will) eventually. Jason From rujbin at protonmail.com Mon Feb 21 21:18:30 2022 From: rujbin at protonmail.com (Rujbin) Date: Mon, 21 Feb 2022 21:18:30 -0000 Subject: MTU Size should be 1280 with details now. Message-ID: Hey, i dont know how mail lists work, as i dont get mails from the whole discussion. I make new Thread with all Details included. I am running Windows 10 Enterprise, Windows 10 Home. My Router is Vodafone Station (Default Router). They might have remote access to fix problems, like all isps do. When i do 1280 MTU, its fine. But its 100mbps maixmum with huge latency drops when i open some websites. My Configurations: [Interface] PrivateKey = HIDDEN Address = 10.0.0.2/32, 2a01::2/128 DNS = 20.199.177.73 MTU = 1280 [Peer] PublicKey = oyq9egDqiRTgxKbvWonrkFavvp9JcIw40EJoWmjRD3Y= AllowedIPs = 0.0.0.0/0, ::/0 Endpoint = 104.248.247.50:51820 PersistentKeepalive = 21 I did not change anything on Interface. Ubuntu Server: ip -a 2: eth0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether fa:04:72:19:7f:4b brd ff:ff:ff:ff:ff:ff inet 104.248.247.50/20 brd 104.248.255.255 scope global eth0 valid_lft forever preferred_lft forever inet 10.19.0.6/16 brd 10.19.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:b0c0:3:d0::16bc:a001/64 scope global valid_lft forever preferred_lft forever inet6 fe80::f804:72ff:fe19:7f4b/64 scope link valid_lft forever preferred_lft forever 63: wg0: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 10.0.0.0/24 scope global wg0 valid_lft forever preferred_lft forever inet6 2a01::/64 scope global valid_lft forever preferred_lft forever Address = 10.0.0.0/24, 2a01:affe:affe:affe:affe:affe:affe:affe/64 Privatekey = HIDDEN Listenport = 51820 PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostUp = ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -t nat -D POSTROUTING -o etho -j MASQUERADE PostDown = ip6tables -t nat -D POSTROUTING -o etho -j MASQUERADE [Peer] Publickey = P7TiJbnXVvLrVCSosZL3ZK1CZHx5OEJf57Q3oejc8RI= AllowedIPs = 10.0.0.3/32, 2a01::3/128 [Peer] PublicKey = tb9edxZH0vdJYYqC8AyF83mkDjra/CoWIoTB584qWF0= AllowedIPs = 10.0.0.2/32, 2a01::2/128 Tracepath: root at ubuntu-s-1vcpu-1gb-intel-fra1-01:~# tracepath 1.1.1.1 1?: [LOCALHOST] pmtu 1500 1: no reply 2: 10.68.132.5 1.609ms asymm 1 3: 138.197.249.62 6.634ms asymm 2 4: 138.197.250.141 0.811ms asymm 3 5: no reply 6: no reply 7: no reply 8: no reply 9: no reply 10: no reply 11: no reply 12: no reply 13: no reply 14: no reply 15: no reply 16: no reply 17: no reply 18: no reply 19: no reply 20: no reply 21: no reply 22: no reply 23: no reply 24: no reply 25: no reply 26: no reply 27: no reply 28: no reply 29: no reply 30: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 Endpoint is always ipv4. What is the problem here? Now, im in Hotel Wifi and 1420 MTU works. But i didnt make something on Network, i dont understand what is wrong... My Server is Ubuntu Server 20.04 LTS with kernel module. From siva131mz at gmail.com Tue Feb 22 12:48:02 2022 From: siva131mz at gmail.com (Siva R) Date: Tue, 22 Feb 2022 12:48:02 -0000 Subject: Need Help - When 2 WireGuard tunnels are active Windows BSOD occurs upon disconnecting/disabling Ethernet NIC Message-ID: Hi.. This is my wg setup 2 Active wg tunnels. Table=Off in both. Routes added/deleted via PostUp and PreDown. Both tunnels have routes configured for subnet 0.0.0.0/0 with low priority(higher interface metric and route metric) So by default all my connections go via Ethernet unless configured in the application to use wg NIC. Problem is when 2 wg tunnels are active Windows BSOD occurs upon disconnecting/disabling Ethernet NIC. It doesn't happen when 1 wg tunnel is active Please let me know if any other information is needed. Happy to share. I've also posted about the anomaly in reddit. https://www.reddit.com/r/WireGuard/comments/syk18j/when_2_wireguard_tunnels_are_active_windows_bsod/ Many thanks. From peter at steel-hub.co.uk Thu Feb 24 00:59:46 2022 From: peter at steel-hub.co.uk (peter at steel-hub.co.uk) Date: Thu, 24 Feb 2022 00:59:46 -0000 Subject: Windows Client - high packet loss after fragmented packet Message-ID: Hello, I am using the wireguard windows client (v0.5.3) and driver (v0.10.1). Whenever I send data that is larger than the mtu, packet loss goes through the roof. Some packets get through, but almost all of them (about 98%) are lost. This will continue until I deactivate and then reactivate the tunnel in the windows client. This does not seem to happen when receiving large packets. However, I haven't spent much time testing that. I tested using an android wireguard client connected to the same server. It had no problems. I used large ping requests to replicate the issue while capturing the traffic on the wg and eth interfaces for both the client and server. When I send a large packet (e.g. 1700 bytes), the client wg interface shows two frames: the first frame length equals the mtu (1420 bytes) and the second makes up the difference + overhead (328 bytes). However, the eth interface on the client only shows the first frame. This is confirmed on the server which only receives the first frame. After a significant delay, the second frame seems to be sent and a response received, but the request has already timed out by then. After that, packets still come and go but there is some kind of delay between packets being received on one interface and appearing on the other. By the time the response comes in, the packet is already considered lost. For example, normal-sized ping requests mostly showed as timed out on the command line but I could see that a response was eventually received on the wg interface. The more large packets I send through the tunnel, the worse it gets. If I just send one large packet, there is a delay and most requests time-out. After more large packets are sent, I stop receiving responses at all on the wg interface. At this point the wireguard client will start reporting handshake failures. As before, deactivating and reactivating the tunnel restores normal operation. Here are some logs that demonstrate the problem: https://we.tl/t-qb1ChyWDIC There are three systems to note: 10.106.15.10 = windows client (win-client) 10.106.0.2 / 10.106.15.1 = wireguard server, debian 11 (server) 10.106.0.3 = test system accessible on lan attached to server, debian 11 (host) Thanks, Peter. From michael at xfs.repair Fri Feb 25 17:31:54 2022 From: michael at xfs.repair (Michael Hicklen) Date: Fri, 25 Feb 2022 17:31:54 -0000 Subject: WireDuard On-Connect DNS Lookup Failure (tries UDP/53, does not fail over to TCP/53) Message-ID: <65VYfOmhDVJ1vrxWr5SuNQBkEUwy8XE6yXij13fOizK7JCUYLoSM_4SXFHM_rhz2JLgsSX0gidKKuEnH7TqxDuFkpQ2OMKXUHe-lgViMrBU=@xfs.repair> Hi all, I've noticed an issue today with WireGuard where it will fail to connect to a hostname when attempting to resolve DNS in a situation where UDP DNS lookups are disabled. This is reproducible by disabling UDP 53 egress, or by connecting to ExpressVPN first then trying to connect WireGuard to a server using a hostname. This is an edge case, but I think it would be excellent if WireGuard were to attempt to fall back on TCP instead of failing out at the UDP lookup. Note this is orthogonal to the endless requests for WireGuard to support TCP tunneling - that is not what I'm talking about here. -- Michael Hicklen michael at xfs.repair