From syzbot+listc4826f4184213affe703 at syzkaller.appspotmail.com Thu May 2 12:38:25 2024 From: syzbot+listc4826f4184213affe703 at syzkaller.appspotmail.com (syzbot) Date: Thu, 02 May 2024 05:38:25 -0700 Subject: [syzbot] Monthly wireguard report (May 2024) Message-ID: <0000000000001bc267061777e143@google.com> Hello wireguard maintainers/developers, This is a 31-day syzbot report for the wireguard subsystem. All related reports/information can be found at: https://syzkaller.appspot.com/upstream/s/wireguard During the period, 2 new issues were detected and 0 were fixed. In total, 4 issues are still open and 16 have been fixed so far. Some of the still happening issues: Ref Crashes Repro Title <1> 939 No KCSAN: data-race in wg_packet_send_staged_packets / wg_packet_send_staged_packets (3) https://syzkaller.appspot.com/bug?extid=6ba34f16b98fe40daef1 <2> 1 No WARNING in __kthread_bind_mask (2) https://syzkaller.appspot.com/bug?extid=36466e0ea21862240631 <3> 1 No WARNING in wg_packet_send_staged_packets https://syzkaller.appspot.com/bug?extid=c369d311130fba58211b --- 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. To disable reminders for individual bugs, reply with the following command: #syz set no-reminders To change bug's subsystems, reply with: #syz set subsystems: new-subsystem You may send multiple commands in a single email message. From edliaw at google.com Thu May 9 19:58:59 2024 From: edliaw at google.com (Edward Liaw) Date: Thu, 9 May 2024 19:58:59 +0000 Subject: [PATCH v3 67/68] selftests/wireguard: Drop define _GNU_SOURCE In-Reply-To: <20240509200022.253089-1-edliaw@google.com> References: <20240509200022.253089-1-edliaw@google.com> Message-ID: <20240509200022.253089-68-edliaw@google.com> _GNU_SOURCE is provided by lib.mk, so it should be dropped to prevent redefinition warnings. Fixes: 809216233555 ("selftests/harness: remove use of LINE_MAX") Signed-off-by: Edward Liaw --- tools/testing/selftests/wireguard/qemu/init.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/testing/selftests/wireguard/qemu/init.c b/tools/testing/selftests/wireguard/qemu/init.c index 3e49924dd77e..08113f3c6189 100644 --- a/tools/testing/selftests/wireguard/qemu/init.c +++ b/tools/testing/selftests/wireguard/qemu/init.c @@ -2,8 +2,6 @@ /* * Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. */ - -#define _GNU_SOURCE #include #include #include -- 2.45.0.118.g7fe29c98d7-goog From edliaw at google.com Fri May 10 00:07:22 2024 From: edliaw at google.com (Edward Liaw) Date: Fri, 10 May 2024 00:07:22 +0000 Subject: [PATCH v4 65/66] selftests/wireguard: Drop define _GNU_SOURCE In-Reply-To: <20240510000842.410729-1-edliaw@google.com> References: <20240510000842.410729-1-edliaw@google.com> Message-ID: <20240510000842.410729-66-edliaw@google.com> _GNU_SOURCE is provided by lib.mk, so it should be dropped to prevent redefinition warnings. Signed-off-by: Edward Liaw --- tools/testing/selftests/wireguard/qemu/init.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/testing/selftests/wireguard/qemu/init.c b/tools/testing/selftests/wireguard/qemu/init.c index 3e49924dd77e..08113f3c6189 100644 --- a/tools/testing/selftests/wireguard/qemu/init.c +++ b/tools/testing/selftests/wireguard/qemu/init.c @@ -2,8 +2,6 @@ /* * Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. */ - -#define _GNU_SOURCE #include #include #include -- 2.45.0.118.g7fe29c98d7-goog From syzbot+943d34fa3cf2191e3068 at syzkaller.appspotmail.com Sat May 11 21:47:30 2024 From: syzbot+943d34fa3cf2191e3068 at syzkaller.appspotmail.com (syzbot) Date: Sat, 11 May 2024 14:47:30 -0700 Subject: [syzbot] [wireguard?] WARNING in kthread_unpark (2) Message-ID: <00000000000061c0a106183499ec@google.com> Hello, syzbot found the following issue on: HEAD commit: 75fa778d74b7 Add linux-next specific files for 20240510 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=13d483c0980000 kernel config: https://syzkaller.appspot.com/x/.config?x=ccdd3ebd6715749a dashboard link: https://syzkaller.appspot.com/bug?extid=943d34fa3cf2191e3068 compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/ad9391835bcf/disk-75fa778d.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/d827b3da9a26/vmlinux-75fa778d.xz kernel image: https://storage.googleapis.com/syzbot-assets/8f32f0182388/bzImage-75fa778d.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+943d34fa3cf2191e3068 at syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 [inline] WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind kernel/kthread.c:538 [inline] WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 kthread_unpark+0x16b/0x210 kernel/kthread.c:631 Modules linked in: CPU: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.9.0-rc7-next-20240510-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__kthread_bind_mask kernel/kthread.c:525 [inline] RIP: 0010:__kthread_bind kernel/kthread.c:538 [inline] RIP: 0010:kthread_unpark+0x16b/0x210 kernel/kthread.c:631 Code: 00 fc ff df 41 0f b6 04 06 84 c0 0f 85 93 00 00 00 41 80 4d 03 04 4c 89 e7 48 8b 34 24 e8 bd c5 32 0a eb 09 e8 46 88 33 00 90 <0f> 0b 90 48 89 ef be 08 00 00 00 e8 75 43 99 00 f0 80 65 00 fb 4c RSP: 0018:ffffc90000107758 EFLAGS: 00010293 RAX: ffffffff8162943a RBX: 0000000000000000 RCX: ffff8880172c3c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88802e430800 R08: ffffffff816293c7 R09: 1ffffffff25f64cd R10: dffffc0000000000 R11: fffffbfff25f64ce R12: 0000000000000001 R13: ffff8880296eda2c R14: 1ffff110052ddb45 R15: ffff8880296eda00 FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd40918ff8 CR3: 000000002e664000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 --- 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. 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 From nico.schottelius at ungleich.ch Tue May 14 10:50:25 2024 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Tue, 14 May 2024 12:50:25 +0200 Subject: Wireguard address binding - how to fix? Message-ID: <87le4cfz0u.fsf@ungleich.ch> Hello, the problem of wireguard being unable to bind to an IP address are hunting us over and over again. Isolation via namespace is not always a solution and I would consider it a hack in the first place. To the wireguard authors: what needs to be done to add IP address binding so that packets are always sent from a specific IP address? Virtually every other network software out there has that option for a good reason, only wireguard does not support it and thus does not work properly on devices with multiple IP addresses. What does it take to add IP address binding in wireguard? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From dxld at darkboxed.org Tue May 14 11:36:48 2024 From: dxld at darkboxed.org (Daniel =?utf-8?Q?Gr=C3=B6ber?=) Date: Tue, 14 May 2024 13:36:48 +0200 Subject: Wireguard address binding - how to fix? In-Reply-To: <87le4cfz0u.fsf@ungleich.ch> References: <87le4cfz0u.fsf@ungleich.ch> Message-ID: <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> On Tue, May 14, 2024 at 12:50:25PM +0200, Nico Schottelius wrote: > To the wireguard authors: what needs to be done to add IP address > binding so that packets are always sent from a specific IP address? Implemented, but wating for Jason to respond: https://lore.kernel.org/netdev/20240219114334.3057169-1-dxld at darkboxed.org/T/ --Daniel From syzbot+8aaf2df2ef0164ffe1fb at syzkaller.appspotmail.com Wed May 15 18:41:26 2024 From: syzbot+8aaf2df2ef0164ffe1fb at syzkaller.appspotmail.com (syzbot) Date: Wed, 15 May 2024 11:41:26 -0700 Subject: [syzbot] [wireguard?] WARNING: locking bug in try_to_wake_up Message-ID: <000000000000516ace0618827799@google.com> Hello, syzbot found the following issue on: HEAD commit: cf87f46fd34d Merge tag 'drm-fixes-2024-05-11' of https://g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16b04970980000 kernel config: https://syzkaller.appspot.com/x/.config?x=6d14c12b661fb43 dashboard link: https://syzkaller.appspot.com/bug?extid=8aaf2df2ef0164ffe1fb compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/1aa5ad92dfce/disk-cf87f46f.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/67c336f7c1c7/vmlinux-cf87f46f.xz kernel image: https://storage.googleapis.com/syzbot-assets/bb5b717bd2b8/bzImage-cf87f46f.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+8aaf2df2ef0164ffe1fb at syzkaller.appspotmail.com ============================= [ BUG: Invalid wait context ] 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Not tainted ----------------------------- kworker/0:5/10404 is trying to lock: ffff8880b953e698 (iattr_mutex){+.+.}-{3:3}, at: raw_spin_rq_lock_nested+0x2a/0x140 kernel/sched/core.c:559 other info that might help us debug this: context-{4:4} 5 locks held by kworker/0:5/10404: #0: ffff888069fd5d48 ((wq_completion)wg-crypt-wg0#12){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3242 [inline] #0: ffff888069fd5d48 ((wq_completion)wg-crypt-wg0#12){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x17c0 kernel/workqueue.c:3348 #1: ffffc9000a4b7d00 ((work_completion)(&({ do { const void *__vpp_verify = (typeof((worker) + 0))((void *)0); (void)__vpp_verify; } while (0); ({ unsigned long __ptr; __ptr = (unsigned long) ((typeof(*((worker))) *)((worker))); (typeof((typeof(*((worker))) *)((worker)))) (__ptr + (((__per_cpu_offset[(cpu)])))); }); })->work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3243 [inline] #1: ffffc9000a4b7d00 ((work_completion)(&({ do { const void *__vpp_verify = (typeof((worker) + 0))((void *)0); (void)__vpp_verify; } while (0); ({ unsigned long __ptr; __ptr = (unsigned long) ((typeof(*((worker))) *)((worker))); (typeof((typeof(*((worker))) *)((worker)))) (__ptr + (((__per_cpu_offset[(cpu)])))); }); })->work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x17c0 kernel/workqueue.c:3348 #2: ffffffff8e334da0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #2: ffffffff8e334da0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:781 [inline] #2: ffffffff8e334da0 (rcu_read_lock){....}-{1:2}, at: __queue_work+0x198/0xef0 kernel/workqueue.c:2337 #3: ffff8880b953de18 (&pool->lock){-.-.}-{2:2}, at: __queue_work+0x6ec/0xef0 #4: ffff8880206b6410 (&p->pi_lock){-.-.}-{2:2}, at: class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:553 [inline] #4: ffff8880206b6410 (&p->pi_lock){-.-.}-{2:2}, at: try_to_wake_up+0xb0/0x1470 kernel/sched/core.c:4262 stack backtrace: CPU: 0 PID: 10404 Comm: kworker/0:5 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-crypt-wg0 wg_packet_encrypt_worker Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_lock_invalid_wait_context kernel/locking/lockdep.c:4751 [inline] check_wait_context kernel/locking/lockdep.c:4821 [inline] __lock_acquire+0x1507/0x1fd0 kernel/locking/lockdep.c:5087 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 raw_spin_rq_lock_nested+0x2a/0x140 kernel/sched/core.c:559 raw_spin_rq_lock kernel/sched/sched.h:1387 [inline] rq_lock kernel/sched/sched.h:1701 [inline] ttwu_queue kernel/sched/core.c:4055 [inline] try_to_wake_up+0x7d3/0x1470 kernel/sched/core.c:4378 kick_pool+0x45c/0x620 kernel/workqueue.c:1288 __queue_work+0xc30/0xef0 kernel/workqueue.c:2414 queue_work_on+0x14f/0x250 kernel/workqueue.c:2448 wg_queue_enqueue_per_peer_tx+0x21f/0x4b0 drivers/net/wireguard/queueing.h:188 wg_packet_encrypt_worker+0x1240/0x1610 drivers/net/wireguard/send.c:305 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3348 worker_thread+0x86d/0xd70 kernel/workqueue.c:3429 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 --- 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. 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 From Jason at zx2c4.com Fri May 17 14:48:02 2024 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 17 May 2024 16:48:02 +0200 Subject: [PATCH v4 65/66] selftests/wireguard: Drop define _GNU_SOURCE In-Reply-To: <20240510000842.410729-66-edliaw@google.com> References: <20240510000842.410729-1-edliaw@google.com> <20240510000842.410729-66-edliaw@google.com> Message-ID: On Fri, May 10, 2024 at 12:07:22AM +0000, Edward Liaw wrote: > _GNU_SOURCE is provided by lib.mk, so it should be dropped to prevent > redefinition warnings. > > Signed-off-by: Edward Liaw > --- > tools/testing/selftests/wireguard/qemu/init.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/tools/testing/selftests/wireguard/qemu/init.c b/tools/testing/selftests/wireguard/qemu/init.c > index 3e49924dd77e..08113f3c6189 100644 > --- a/tools/testing/selftests/wireguard/qemu/init.c > +++ b/tools/testing/selftests/wireguard/qemu/init.c > @@ -2,8 +2,6 @@ > /* > * Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. > */ > - > -#define _GNU_SOURCE > #include > #include > #include > -- But this file doesn't use lib.mk. From nico.schottelius at ungleich.ch Tue May 21 07:21:11 2024 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Tue, 21 May 2024 09:21:11 +0200 Subject: Wireguard address binding - how to fix? In-Reply-To: <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> ("Daniel =?utf-8?Q?Gr=C3=B6ber=22's?= message of "Tue, 14 May 2024 13:36:48 +0200") References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> Message-ID: <87msojhbq0.fsf@ungleich.ch> Hello Jason, do you mind applying the patch from Daniel? Or is there anything wrong with it? Daniel: amazing work, I was not aware that you have already put in the hard work, thank you so very much! The world (*) is suffering because of the lack of IP address binding in wireguard. Best regards, Nico (*) With world I refer to every engineer that needs to run wireguard in non-trivial situations with multiple IP addresses on one host, which is extremely common for anything that routes. Daniel Gr?ber writes: > On Tue, May 14, 2024 at 12:50:25PM +0200, Nico Schottelius wrote: >> To the wireguard authors: what needs to be done to add IP address >> binding so that packets are always sent from a specific IP address? > > Implemented, but wating for Jason to respond: > https://lore.kernel.org/netdev/20240219114334.3057169-1-dxld at darkboxed.org/T/ > > --Daniel -------------- next part -------------- -- Sustainable and modern Infrastructures by ungleich.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From icepic.dz at gmail.com Tue May 21 11:11:00 2024 From: icepic.dz at gmail.com (Janne Johansson) Date: Tue, 21 May 2024 13:11:00 +0200 Subject: Wireguard address binding - how to fix? In-Reply-To: <87msojhbq0.fsf@ungleich.ch> References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> Message-ID: Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius : > Hello Jason, > do you mind applying the patch from Daniel? Or is there anything wrong with it? > > Daniel: amazing work, I was not aware that you have already put in the > hard work, thank you so very much! > > The world (*) is suffering because of the lack of IP address binding in wireguard. > > (*) With world I refer to every engineer that needs to run wireguard in > non-trivial situations with multiple IP addresses on one host, which is > extremely common for anything that routes. Well, the main reason for wg to NOT do anything special is because routing generally is done by looking at the destination ip and then using the routing rules which the kernel uses to tell the packet which interface is considered "best" in order to reach that ip, which is why icmp and udp acts like this. I am certain that many engineers hope/think it would be more logical (or fit their designs better) if it responded on the same interface as the packet came in or whatever but the reason for wg to act like it does is because this is how connection-less packets have been acting since ages. The point that many engineers design wg endpoints "the wrong way" is probably a fault of education when it comes to how TCP/IP stacks did and do manage IP output. I have zero power to decide anything regarding how wg chooses to implement a workaround for IP being designed the way it is designed, but I can at least see why it hasn't immediately been accepted even if it would make some engineers suffer(*) less, at least in the short term. There are a lot of workarounds for the times when you did design the udp service as if it would act like tcp does in multihomed situations, which includes firewall tricks, or VRF/namespace/routing-domains to make sure the inner and outer address-pairs for the wg tunnel see different views of the network to handle this without changing how wg sends packets. -- May the most significant bit of your life be positive. From nico.schottelius at ungleich.ch Tue May 21 12:58:40 2024 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Tue, 21 May 2024 14:58:40 +0200 Subject: Wireguard address binding - how to fix? In-Reply-To: (Janne Johansson's message of "Tue, 21 May 2024 13:11:00 +0200") References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> Message-ID: <87a5kjgw3j.fsf@ungleich.ch> Hello Janne, Janne Johansson writes: > Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius > : >> Hello Jason, >> do you mind applying the patch from Daniel? Or is there anything wrong with it? >> >> Daniel: amazing work, I was not aware that you have already put in the >> hard work, thank you so very much! >> >> The world (*) is suffering because of the lack of IP address binding in wireguard. >> >> (*) With world I refer to every engineer that needs to run wireguard in >> non-trivial situations with multiple IP addresses on one host, which is >> extremely common for anything that routes. > > Well, the main reason for wg to NOT do anything special is because > routing generally is done by looking at the destination ip and then No. Generally speaking that is incorrect. It is not special to reply with the same IP address. Generally speaking, when you have systems with multiple IP addresses you want to be able to steer the binding to an IP address. And even if you don't do that, you reply with the same IP address you have been contacted with. Wireguard does neither of it at the moment. I have written this already many times on this list, but the reason is very easy: - A connection is initiated from device A, connecting to router B on IP adddress a.b.c.d - The packet is correctly received by router B - The router replies incorrectly with address f.d.g.h - The reply packet is correctly blocked at the firewall of device A, because it comes from a random, unknown IP address This is the basic 101 of networking is to reply with the same address you have been contacted with, there is no discussion necessary. The whole world does it, even A-patch-y httpd (*) supports it. Since 1980 or so. Routing choices are independent of that, replying with the same IP address is a standard behaviour. Nico (*) As does ssh, nginx, ipsec protocols, openvpn, any rails application, any python application - I am not sure which software that binds to a socket does not support it, with the exception of wireguard. -------------- next part -------------- -- Sustainable and modern Infrastructures by ungleich.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From sh at keff.org Tue May 21 14:11:31 2024 From: sh at keff.org (Sebastian Hyrvall) Date: Tue, 21 May 2024 21:11:31 +0700 Subject: Wireguard address binding - how to fix? In-Reply-To: <87a5kjgw3j.fsf@ungleich.ch> References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> <87a5kjgw3j.fsf@ungleich.ch> Message-ID: The reason wireguard does it like this I think is because when designing it there was no thought given to any client,server scenario. Both sides are behaving like clients that can jump between IPs at any time. This is a flawed concept given that in 90% of scenarios there is at least one side acting as a server on a static ip. Unless the server side is a home user on dynamic ip and rebinding could be difficult. I've also given a bit of thought to the security aspect of this for VPN providers. Since a remote party can override the configured "Endpoint" if there was a scenario where vpn provider privkeys are compromised. The attacker can then, by knowing the connecting clients ip, get him to shift over the tunnel to their server and perform a long term, most likely undetected, mitm attack. Anyway. I've waited for this binding option for years. It's insane to me it gets ignored. One product is for example Mikrotik hardware. They don't want to implement third party patches so they are waiting for this bind-patch to be included in the kernel. Until then we're forced to use OpenVPN in our setups. On 2024-05-21 19:58, Nico Schottelius wrote: > Hello Janne, > > Janne Johansson writes: > >> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius >> : >>> Hello Jason, >>> do you mind applying the patch from Daniel? Or is there anything wrong with it? >>> >>> Daniel: amazing work, I was not aware that you have already put in the >>> hard work, thank you so very much! >>> >>> The world (*) is suffering because of the lack of IP address binding in wireguard. >>> >>> (*) With world I refer to every engineer that needs to run wireguard in >>> non-trivial situations with multiple IP addresses on one host, which is >>> extremely common for anything that routes. >> Well, the main reason for wg to NOT do anything special is because >> routing generally is done by looking at the destination ip and then > No. Generally speaking that is incorrect. > It is not special to reply with the same IP address. > > Generally speaking, when you have systems with multiple IP addresses you > want to be able to steer the binding to an IP address. And even if you > don't do that, you reply with the same IP address you have been > contacted with. Wireguard does neither of it at the moment. I have > written this already many times on this list, but the reason is very > easy: > > - A connection is initiated from device A, connecting to router B on IP adddress a.b.c.d > - The packet is correctly received by router B > - The router replies incorrectly with address f.d.g.h > - The reply packet is correctly blocked at the firewall of device A, because it comes > from a random, unknown IP address > > This is the basic 101 of networking is to reply with the same address > you have been contacted with, there is no discussion necessary. The > whole world does it, even A-patch-y httpd (*) supports it. Since 1980 or > so. > > Routing choices are independent of that, replying with the same IP > address is a standard behaviour. > > Nico > > (*) As does ssh, nginx, ipsec protocols, openvpn, any rails application, > any python application - I am not sure which software that binds to a > socket does not support it, with the exception of wireguard. > > From nico.schottelius at ungleich.ch Tue May 21 14:34:04 2024 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Tue, 21 May 2024 16:34:04 +0200 Subject: Wireguard address binding - how to fix? In-Reply-To: (Sebastian Hyrvall's message of "Tue, 21 May 2024 21:11:31 +0700") References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> <87a5kjgw3j.fsf@ungleich.ch> Message-ID: <874jarfd43.fsf@ungleich.ch> Hey Sebastian, Sebastian Hyrvall writes: > [...] > Anyway. I've waited for this binding option for years. It's insane to > me it gets ignored. I have to second this very strongly. > One product is for example Mikrotik hardware. They don't want to > implement third party patches so they are waiting for this bind-patch > to be included in the kernel. Until then we're forced to use OpenVPN > in our setups. As well as this one. As written in the previous mail, virtually every established networking software out there supports IP address binding, with the exception of wireguard. Dear wireguard authors, can be go into the direction of accepting an already written patch (thanks again Daniel) or if that patch is not suitable for some reason at least discuss what needs to be changed so that IP address binding can make its way into wireguard? BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch From tbskyd at gmail.com Sun May 26 03:59:50 2024 From: tbskyd at gmail.com (d tbsky) Date: Sun, 26 May 2024 11:59:50 +0800 Subject: Wireguard address binding - how to fix? In-Reply-To: <874jarfd43.fsf@ungleich.ch> References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> <87a5kjgw3j.fsf@ungleich.ch> <874jarfd43.fsf@ungleich.ch> Message-ID: > Sebastian Hyrvall writes: > > [...] > > Anyway. I've waited for this binding option for years. It's insane to > > me it gets ignored. I remembered how exciting when I tested wireguard at 2017. until I asked muti-home question in the list. wiregurad is beautiful,elegant,fast but not easy to get along with. openvpn is not so amazing but it can get the job done. From syzbot+f19160c19b77d76b5bc2 at syzkaller.appspotmail.com Sun May 26 06:16:21 2024 From: syzbot+f19160c19b77d76b5bc2 at syzkaller.appspotmail.com (syzbot) Date: Sat, 25 May 2024 23:16:21 -0700 Subject: [syzbot] [wireguard?] WARNING: locking bug in wg_packet_encrypt_worker Message-ID: <000000000000f2562606195556e5@google.com> Hello, syzbot found the following issue on: HEAD commit: 2a8120d7b482 Merge tag 's390-6.10-2' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=150fd9cc980000 kernel config: https://syzkaller.appspot.com/x/.config?x=5dd4fde1337a9e18 dashboard link: https://syzkaller.appspot.com/bug?extid=f19160c19b77d76b5bc2 compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-2a8120d7.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/78c72ae6bdaf/vmlinux-2a8120d7.xz kernel image: https://storage.googleapis.com/syzbot-assets/99dbb805b738/bzImage-2a8120d7.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f19160c19b77d76b5bc2 at syzkaller.appspotmail.com ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 2 PID: 5289 at kernel/locking/lockdep.c:232 hlock_class kernel/locking/lockdep.c:232 [inline] WARNING: CPU: 2 PID: 5289 at kernel/locking/lockdep.c:232 hlock_class+0xfa/0x130 kernel/locking/lockdep.c:221 Modules linked in: CPU: 2 PID: 5289 Comm: kworker/2:5 Not tainted 6.9.0-syzkaller-10713-g2a8120d7b482 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: wg-crypt-wg0 wg_packet_encrypt_worker RIP: 0010:hlock_class kernel/locking/lockdep.c:232 [inline] RIP: 0010:hlock_class+0xfa/0x130 kernel/locking/lockdep.c:221 Code: b6 14 11 38 d0 7c 04 84 d2 75 43 8b 05 53 0b 77 0e 85 c0 75 19 90 48 c7 c6 00 bb 2c 8b 48 c7 c7 a0 b5 2c 8b e8 f7 40 e5 ff 90 <0f> 0b 90 90 90 31 c0 eb 9e e8 58 f7 7f 00 e9 1c ff ff ff 48 c7 c7 RSP: 0018:ffffc900030c7960 EFLAGS: 00010086 RAX: 0000000000000000 RBX: 00000000000019e3 RCX: ffffffff81510229 RDX: ffff8880203e0000 RSI: ffffffff81510236 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 000000002d2d2d2d R12: 0000000000000000 R13: 0000000000000000 R14: ffff8880203e0b30 R15: 00000000000019e3 FS: 0000000000000000(0000) GS:ffff88802c200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c000873681 CR3: 000000004adc0000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: check_wait_context kernel/locking/lockdep.c:4773 [inline] __lock_acquire+0x3f2/0x3b30 kernel/locking/lockdep.c:5087 lock_acquire kernel/locking/lockdep.c:5754 [inline] lock_acquire+0x1b1/0x560 kernel/locking/lockdep.c:5719 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x33/0x40 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:365 [inline] wg_packet_encrypt_worker+0xe4/0xb60 drivers/net/wireguard/send.c:293 process_one_work+0x958/0x1ad0 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 --- 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. 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 From nico.schottelius at ungleich.ch Sun May 26 08:57:52 2024 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Sun, 26 May 2024 10:57:52 +0200 Subject: Wireguard address binding - how to fix? In-Reply-To: (d. tbsky's message of "Sun, 26 May 2024 11:59:50 +0800") References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> <87a5kjgw3j.fsf@ungleich.ch> <874jarfd43.fsf@ungleich.ch> Message-ID: <87bk4tc5m7.fsf@ungleich.ch> d tbsky writes: > I remembered how exciting when I tested wireguard at 2017. until I > asked muti-home question in the list. > wiregurad is beautiful,elegant,fast but not easy to get along with. > openvpn is not so amazing but it can get the job done. Nice summary, hits the nail quite well. Jason, do you mind having a look at the submitted patches for IP address binding and comment on them? Or alternatively can you give green light for generally moving forward so that a direct inclusion in the Linux kernel would be accepted? Best regards, Nico -------------- next part -------------- -- Sustainable and modern Infrastructures by ungleich.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From syzbot+470d70be7e9ee9f22a01 at syzkaller.appspotmail.com Mon May 27 07:24:29 2024 From: syzbot+470d70be7e9ee9f22a01 at syzkaller.appspotmail.com (syzbot) Date: Mon, 27 May 2024 00:24:29 -0700 Subject: [syzbot] [wireguard?] general protection fault in wg_packet_receive Message-ID: <00000000000070dbbd06196a68ea@google.com> Hello, syzbot found the following issue on: HEAD commit: 2a8120d7b482 Merge tag 's390-6.10-2' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10263a34980000 kernel config: https://syzkaller.appspot.com/x/.config?x=5dd4fde1337a9e18 dashboard link: https://syzkaller.appspot.com/bug?extid=470d70be7e9ee9f22a01 compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-2a8120d7.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/78c72ae6bdaf/vmlinux-2a8120d7.xz kernel image: https://storage.googleapis.com/syzbot-assets/99dbb805b738/bzImage-2a8120d7.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+470d70be7e9ee9f22a01 at syzkaller.appspotmail.com Oops: general protection fault, probably for non-canonical address 0xdffffc001ffff113: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: probably user-memory-access in range [0x00000000ffff8898-0x00000000ffff889f] CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.9.0-syzkaller-10713-g2a8120d7b482 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: wg-kex-wg1 wg_packet_handshake_receive_worker RIP: 0010:__lock_acquire+0xe3e/0x3b30 kernel/locking/lockdep.c:5005 Code: 11 00 00 39 05 b3 cf 1f 12 0f 82 be 05 00 00 ba 01 00 00 00 e9 e4 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 82 1f 00 00 49 81 3c 24 a0 3d e3 92 0f 84 98 f2 RSP: 0018:ffffc90000007500 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 000000001ffff113 RSI: ffff888015f20000 RDI: 00000000ffff8898 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff8fe29817 R11: 0000000000000004 R12: 00000000ffff8898 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88802c000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c0016a3000 CR3: 000000005dcac000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: lock_acquire kernel/locking/lockdep.c:5754 [inline] lock_acquire+0x1b1/0x560 kernel/locking/lockdep.c:5719 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 __queue_work+0x39e/0x1020 kernel/workqueue.c:2319 queue_work_on+0x11a/0x140 kernel/workqueue.c:2410 wg_packet_receive+0x13ea/0x2350 drivers/net/wireguard/receive.c:570 wg_receive+0x74/0xc0 drivers/net/wireguard/socket.c:326 udp_queue_rcv_one_skb+0xad1/0x18b0 net/ipv4/udp.c:2131 udp_queue_rcv_skb+0x198/0xd10 net/ipv4/udp.c:2209 udp_unicast_rcv_skb+0x165/0x3b0 net/ipv4/udp.c:2369 __udp4_lib_rcv+0x2636/0x3550 net/ipv4/udp.c:2445 ip_protocol_deliver_rcu+0x30c/0x4e0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x316/0x570 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip_local_deliver+0x18e/0x1f0 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip_rcv+0x2c5/0x5d0 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 net/core/dev.c:5624 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5738 process_backlog+0x133/0x760 net/core/dev.c:6067 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6721 napi_poll net/core/dev.c:6790 [inline] net_rx_action+0x9b6/0xf10 net/core/dev.c:6906 handle_softirqs+0x216/0x8f0 kernel/softirq.c:554 do_softirq kernel/softirq.c:455 [inline] do_softirq+0xb2/0xf0 kernel/softirq.c:442 __local_bh_enable_ip+0x100/0x120 kernel/softirq.c:382 wg_socket_send_skb_to_peer+0x14c/0x220 drivers/net/wireguard/socket.c:184 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_response+0x297/0x310 drivers/net/wireguard/send.c:103 wg_receive_handshake_packet+0x248/0xbf0 drivers/net/wireguard/receive.c:154 wg_packet_handshake_receive_worker+0x17f/0x3a0 drivers/net/wireguard/receive.c:213 process_one_work+0x958/0x1ad0 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__lock_acquire+0xe3e/0x3b30 kernel/locking/lockdep.c:5005 Code: 11 00 00 39 05 b3 cf 1f 12 0f 82 be 05 00 00 ba 01 00 00 00 e9 e4 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 82 1f 00 00 49 81 3c 24 a0 3d e3 92 0f 84 98 f2 RSP: 0018:ffffc90000007500 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 000000001ffff113 RSI: ffff888015f20000 RDI: 00000000ffff8898 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff8fe29817 R11: 0000000000000004 R12: 00000000ffff8898 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88802c000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c0016a3000 CR3: 000000005dcac000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---------------- Code disassembly (best guess): 0: 11 00 adc %eax,(%rax) 2: 00 39 add %bh,(%rcx) 4: 05 b3 cf 1f 12 add $0x121fcfb3,%eax 9: 0f 82 be 05 00 00 jb 0x5cd f: ba 01 00 00 00 mov $0x1,%edx 14: e9 e4 00 00 00 jmp 0xfd 19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax 20: fc ff df 23: 4c 89 e2 mov %r12,%rdx 26: 48 c1 ea 03 shr $0x3,%rdx * 2a: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction 2e: 0f 85 82 1f 00 00 jne 0x1fb6 34: 49 81 3c 24 a0 3d e3 cmpq $0xffffffff92e33da0,(%r12) 3b: 92 3c: 0f .byte 0xf 3d: 84 .byte 0x84 3e: 98 cwtl 3f: f2 repnz --- 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. 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 From syzbot+a6bdd2d02402f18fdd5e at syzkaller.appspotmail.com Wed May 29 01:04:24 2024 From: syzbot+a6bdd2d02402f18fdd5e at syzkaller.appspotmail.com (syzbot) Date: Tue, 28 May 2024 18:04:24 -0700 Subject: [syzbot] [wireguard?] INFO: task hung in wg_destruct Message-ID: <000000000000d9551e06198d54b4@google.com> Hello, syzbot found the following issue on: HEAD commit: e0cce98fe279 Merge tag 'tpmdd-next-6.10-rc2' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1040c63a980000 kernel config: https://syzkaller.appspot.com/x/.config?x=47d282ddffae809f dashboard link: https://syzkaller.appspot.com/bug?extid=a6bdd2d02402f18fdd5e compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/2739658d66f3/disk-e0cce98f.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/ad17bcdfd78d/vmlinux-e0cce98f.xz kernel image: https://storage.googleapis.com/syzbot-assets/31990c7700ed/bzImage-e0cce98f.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+a6bdd2d02402f18fdd5e at syzkaller.appspotmail.com INFO: task kworker/u8:2:35 blocked for more than 143 seconds. Not tainted 6.10.0-rc1-syzkaller-00021-ge0cce98fe279 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:2 state:D stack:14456 pid:35 tgid:35 ppid:2 flags:0x00004000 Workqueue: netns cleanup_net Call Trace: context_switch kernel/sched/core.c:5408 [inline] __schedule+0x1796/0x49d0 kernel/sched/core.c:6745 __schedule_loop kernel/sched/core.c:6822 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6837 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6894 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x6a4/0xd70 kernel/locking/mutex.c:752 wg_destruct+0x25/0x2e0 drivers/net/wireguard/device.c:246 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10692 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11760 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 INFO: task kworker/u8:12:8583 blocked for more than 143 seconds. Not tainted 6.10.0-rc1-syzkaller-00021-ge0cce98fe279 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:12 state:D stack:21976 pid:8583 tgid:8583 ppid:2 flags:0x00004000 Workqueue: ipv6_addrconf addrconf_verify_work Call Trace: context_switch kernel/sched/core.c:5408 [inline] __schedule+0x1796/0x49d0 kernel/sched/core.c:6745 --- 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. 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 From syzbot+1d5c9cd5bcdce13e618e at syzkaller.appspotmail.com Thu May 30 10:55:23 2024 From: syzbot+1d5c9cd5bcdce13e618e at syzkaller.appspotmail.com (syzbot) Date: Thu, 30 May 2024 03:55:23 -0700 Subject: [syzbot] [wireguard?] INFO: task hung in wg_netns_pre_exit (4) Message-ID: <0000000000002aadc50619a9b4d5@google.com> Hello, syzbot found the following issue on: HEAD commit: 4a4be1ad3a6e Revert "vfs: Delete the associated dentry whe.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14003162980000 kernel config: https://syzkaller.appspot.com/x/.config?x=b9016f104992d69c dashboard link: https://syzkaller.appspot.com/bug?extid=1d5c9cd5bcdce13e618e compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/fd3b4fa0291b/disk-4a4be1ad.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/d58e4ceaeff3/vmlinux-4a4be1ad.xz kernel image: https://storage.googleapis.com/syzbot-assets/4df89f1b7d3b/bzImage-4a4be1ad.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+1d5c9cd5bcdce13e618e at syzkaller.appspotmail.com INFO: task kworker/u8:0:11 blocked for more than 143 seconds. Not tainted 6.10.0-rc1-syzkaller-00027-g4a4be1ad3a6e #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack:20632 pid:11 tgid:11 ppid:2 flags:0x00004000 Workqueue: netns cleanup_net Call Trace: context_switch kernel/sched/core.c:5408 [inline] __schedule+0x17e8/0x4a20 kernel/sched/core.c:6745 __schedule_loop kernel/sched/core.c:6822 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6837 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6894 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x6a4/0xd70 kernel/locking/mutex.c:752 wg_netns_pre_exit+0x1f/0x1e0 drivers/net/wireguard/device.c:414 ops_pre_exit_list net/core/net_namespace.c:163 [inline] cleanup_net+0x617/0xcc0 net/core/net_namespace.c:620 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2e/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 INFO: task kworker/1:1:45 blocked for more than 144 seconds. Not tainted 6.10.0-rc1-syzkaller-00027-g4a4be1ad3a6e #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:1 state:D stack:22064 pid:45 tgid:45 ppid:2 flags:0x00004000 Workqueue: events linkwatch_event Call Trace: context_switch kernel/sched/core.c:5408 [inline] __schedule+0x17e8/0x4a20 kernel/sched/core.c:6745 __schedule_loop kernel/sched/core.c:6822 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6837 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6894 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x6a4/0xd70 kernel/locking/mutex.c:752 --- 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. 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 From cheinasso.francesco at gmail.com Tue May 28 08:21:36 2024 From: cheinasso.francesco at gmail.com (Francesco Cheinasso) Date: Tue, 28 May 2024 08:21:36 -0000 Subject: Wireguard-go: flags refactoring proposal Message-ID: Hi, I'm Francesco Cheinasso, an open-source developer from the project liqo (https://github.com/liqotech/liqo). First of all, thanks for your excellent work and for sharing it with the open-source community. In liqo, we are integrating wireguard-go as an alternative for users with old kernel, but we are facing a problem, it's not possible to set the MTU at the moment in wireguard-go. I'm taking a look at the code, to add the possibility to specify the MTU, a flag refactoring should be necessary. It would bother you if we take care of a flag refactoring inside wireguard-go? Regards Francesco Cheinasso From ralaoui at protonmail.com Mon May 6 09:02:01 2024 From: ralaoui at protonmail.com (Rachid Alaoui) Date: Mon, 06 May 2024 09:02:01 -0000 Subject: Leaks when using kernel module backend on Android Message-ID: Hello all, I have recently configured a WireGuard tunnel between my Android phone and a CentOS Server. The userspace backend implementation functions as expected, I also get the key icon in the status bar on Android. After granting root access to the WireGuard app and enabling the kernel module backend, I discovered that some traffic was being routed outside the tunnel. To confirm this, I created a dummy VPN profile and connected to it. As expected, I lost internet access entirely. However, suprisingly, I still received notifications from Firebase Cloud Messaging (FCM). Additionally, the key icon is missing from the status bar when using the kernel module backend. Stock Android with Google Play Services Wireguard for Android : v1.0.20231018 Kernel module backend : v1.0.0 Best, Rachid Alaoui -------------- next part -------------- A non-text attachment was scrubbed... Name: wireguard.png Type: image/png Size: 227787 bytes Desc: not available URL: From skraw.ml at ithnet.com Tue May 21 12:55:45 2024 From: skraw.ml at ithnet.com (Stephan von Krawczynski) Date: Tue, 21 May 2024 12:55:45 -0000 Subject: Wireguard address binding - how to fix? In-Reply-To: References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> Message-ID: <20240521145541.7f13c632@ithnet.com> Hello Janne, I know that most people dealing with wg do not really understand how a box works that has more than one IP and one interface. A simple question: an interface has 100 IP addresses, how do you choose in wg on which IP your tunnel end is? Can you please (all wg infected) understand that about every box that has a redundancy setup has several IPs per interface and you want wg connect to the _right_ one, because this is the one taken over in case of failover. The question is not about interface for routing, the question is about LISTEN_ADDR. I always thought it cannot get worse, but then came wg... -- Regards, Stephan On Tue, 21 May 2024 13:11:00 +0200 Janne Johansson wrote: > Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius > : > > Hello Jason, > > do you mind applying the patch from Daniel? Or is there anything wrong > > with it? > > > > Daniel: amazing work, I was not aware that you have already put in the > > hard work, thank you so very much! > > > > The world (*) is suffering because of the lack of IP address binding in > > wireguard. > > > > (*) With world I refer to every engineer that needs to run wireguard in > > non-trivial situations with multiple IP addresses on one host, which is > > extremely common for anything that routes. > > Well, the main reason for wg to NOT do anything special is because > routing generally is done by looking at the destination ip and then > using the routing rules which the kernel uses to tell the packet which > interface is considered "best" in order to reach that ip, which is why > icmp and udp acts like this. I am certain that many engineers > hope/think it would be more logical (or fit their designs better) if > it responded on the same interface as the packet came in or whatever > but the reason for wg to act like it does is because this is how > connection-less packets have been acting since ages. The point that > many engineers design wg endpoints "the wrong way" is probably a fault > of education when it comes to how TCP/IP stacks did and do manage IP > output. > > I have zero power to decide anything regarding how wg chooses to > implement a workaround for IP being designed the way it is designed, > but I can at least see why it hasn't immediately been accepted even if > it would make some engineers suffer(*) less, at least in the short > term. > > There are a lot of workarounds for the times when you did design the > udp service as if it would act like tcp does in multihomed situations, > which includes firewall tricks, or VRF/namespace/routing-domains to > make sure the inner and outer address-pairs for the wg tunnel see > different views of the network to handle this without changing how wg > sends packets. > > -- > May the most significant bit of your life be positive. From skraw at ithnet.com Wed May 22 08:53:23 2024 From: skraw at ithnet.com (Stephan von Krawczynski) Date: Wed, 22 May 2024 08:53:23 -0000 Subject: Wireguard address binding - how to fix? In-Reply-To: References: <87le4cfz0u.fsf@ungleich.ch> <20240514113648.neaj6kfazx4fi7af@House.clients.dxld.at> <87msojhbq0.fsf@ungleich.ch> <87a5kjgw3j.fsf@ungleich.ch> Message-ID: <20240522105319.61f7c0e6@ithnet.com> Hello Sebastian, great to hear that you came to the same conclusion regarding the security of wg. You have never read me on the list as I get continuously censored away from it. Obviously because my first post 3 years ago was exactly this: ######################### From: Stephan von Krawczynski To: wireguard at lists.zx2c4.com Subject: How to set source ip of wireguard packets? Date: Tue, 20 Oct 2020 13:27:46 +0200 Organization: ith Kommunikationstechnik GmbH X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Hello all, configuring wireguard for the first time I ran into a question I could not find any answer in the docs, so: Lets assume both client and server have several IPs on their outgoing interface. How do you setup wireguard so that a specific IP is used as source ip in the outgoing encrypted packets? This is important in failover-setups where a VIP moves between some physical hosts and we don't want to listen on the physical IPs but only the VIP ... I would have expected this to be specified in "ListenPort" optionally like "ListenPort = IP:PORT", but that does not work currently. -- Regards, Stephan ############################### Ever since I was censored away. I came to the same conclusion, which is that wg is in fact only an orchestrated way to get vpn over the world completely open to mitm attacks, just like your conclusion. Even better the very same people always talk about the insecurity of PPTP, completely dumping the fact that every PPP since the very beginning has a (script) interface where you can check the connecting _IPs_ and users. We don't talk about the encryption security here, because I bet that we all cannot analyse this point in wg, away from the fact the special implementation should be deeply reviewed, too. Therefore we judge the current wg as high security risk which should not be used in professional environment. A VPN where you cannot even verify the connecting IP? Gimme a break ... Being one of the last "forkers" of the cipe project where all wg problems were solved decades ago we do really wonder why this project gets so much code support being so badly designed from the start. That is why we think it is orchestrated by interested parties. While we're at it, the very same seems to be going on in the certificate business where it is prevented for decades by the browser people to use self-signed certificates which could be verified dead easy by a pointer in the corresponding domains' dns-record. We are not amused. -- Regards Stephan On Tue, 21 May 2024 21:11:31 +0700 Sebastian Hyrvall wrote: > The reason wireguard does it like this I think is because when designing > it there was no thought given to any client,server scenario. > > Both sides are behaving like clients that can jump between IPs at any > time. This is a flawed concept given that in 90% of scenarios there > is at least one side acting as a server on a static ip. Unless the > server side is a home user on dynamic ip and rebinding could be difficult. > > I've also given a bit of thought to the security aspect of this for VPN > providers. Since a remote party can override the configured "Endpoint" > if there was a scenario where vpn provider privkeys are > compromised. The attacker can then, by knowing the connecting clients > ip, get him to shift over the tunnel to their server and perform a long > term, most likely undetected, mitm attack. > > Anyway. I've waited for this binding option for years. It's insane to me > it gets ignored. > > One product is for example Mikrotik hardware. They don't want to > implement third party patches so they are waiting for this bind-patch to > be included in the kernel. Until then we're forced to use OpenVPN in our > setups. > > > On 2024-05-21 19:58, Nico Schottelius wrote: > > Hello Janne, > > > > Janne Johansson writes: > > > >> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius > >> : > >>> Hello Jason, > >>> do you mind applying the patch from Daniel? Or is there anything wrong > >>> with it? > >>> > >>> Daniel: amazing work, I was not aware that you have already put in the > >>> hard work, thank you so very much! > >>> > >>> The world (*) is suffering because of the lack of IP address binding in > >>> wireguard. > >>> > >>> (*) With world I refer to every engineer that needs to run wireguard in > >>> non-trivial situations with multiple IP addresses on one host, which is > >>> extremely common for anything that routes. > >> Well, the main reason for wg to NOT do anything special is because > >> routing generally is done by looking at the destination ip and then > > No. Generally speaking that is incorrect. > > It is not special to reply with the same IP address. > > > > Generally speaking, when you have systems with multiple IP addresses you > > want to be able to steer the binding to an IP address. And even if you > > don't do that, you reply with the same IP address you have been > > contacted with. Wireguard does neither of it at the moment. I have > > written this already many times on this list, but the reason is very > > easy: > > > > - A connection is initiated from device A, connecting to router B on IP > > adddress a.b.c.d > > - The packet is correctly received by router B > > - The router replies incorrectly with address f.d.g.h > > - The reply packet is correctly blocked at the firewall of device A, > > because it comes from a random, unknown IP address > > > > This is the basic 101 of networking is to reply with the same address > > you have been contacted with, there is no discussion necessary. The > > whole world does it, even A-patch-y httpd (*) supports it. Since 1980 or > > so. > > > > Routing choices are independent of that, replying with the same IP > > address is a standard behaviour. > > > > Nico > > > > (*) As does ssh, nginx, ipsec protocols, openvpn, any rails application, > > any python application - I am not sure which software that binds to a > > socket does not support it, with the exception of wireguard. > > > >