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 <Ref> no-reminders

To change bug's subsystems, reply with:
#syz set <Ref> 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 <edliaw at google.com>
---
 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 <Jason at zx2c4.com>. All Rights Reserved.
  */
-
-#define _GNU_SOURCE
 #include <unistd.h>
 #include <errno.h>
 #include <string.h>
-- 
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 <edliaw at google.com>
---
 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 <Jason at zx2c4.com>. All Rights Reserved.
  */
-
-#define _GNU_SOURCE
 #include <unistd.h>
 #include <errno.h>
 #include <string.h>
-- 
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:
 <TASK>
 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
 </TASK>


---
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: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20240514/2d33e861/attachment.sig>

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:
 <TASK>
 __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
 </TASK>


---
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: <ZkduIlhF2XswiAJr@zx2c4.com>

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 <edliaw at google.com>
> ---
>  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 <Jason at zx2c4.com>. All Rights Reserved.
>   */
> -
> -#define _GNU_SOURCE
>  #include <unistd.h>
>  #include <errno.h>
>  #include <string.h>
> -- 

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 <dxld at darkboxed.org> 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: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20240521/140c98b1/attachment.sig>

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: <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com>

Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
<nico.schottelius at 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.
>
> (*) 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: <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com>
 (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>
 <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com>
Message-ID: <87a5kjgw3j.fsf@ungleich.ch>


Hello Janne,

Janne Johansson <icepic.dz at gmail.com> writes:

> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
> <nico.schottelius at 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.
>>
>> (*) 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: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20240521/4a7004ee/attachment.sig>

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>
 <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com>
 <87a5kjgw3j.fsf@ungleich.ch>
Message-ID: <f292656a-52c8-4258-8b6a-45064a702a8a@keff.org>

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 <icepic.dz at gmail.com> writes:
>
>> Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius
>> <nico.schottelius at 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.
>>>
>>> (*) 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: <f292656a-52c8-4258-8b6a-45064a702a8a@keff.org> (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>
 <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com>
 <87a5kjgw3j.fsf@ungleich.ch>
 <f292656a-52c8-4258-8b6a-45064a702a8a@keff.org>
Message-ID: <874jarfd43.fsf@ungleich.ch>


Hey Sebastian,


Sebastian Hyrvall <sh at keff.org> 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>
 <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com>
 <87a5kjgw3j.fsf@ungleich.ch> <f292656a-52c8-4258-8b6a-45064a702a8a@keff.org>
 <874jarfd43.fsf@ungleich.ch>
Message-ID: <CAC6SzHJFRNPsLNSd7_w8qQwtyfHLvZtf5SeTS-gvAcY_wAidXQ@mail.gmail.com>

> Sebastian Hyrvall <sh at keff.org> 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:
 <TASK>
 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
 </TASK>


---
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: <CAC6SzHJFRNPsLNSd7_w8qQwtyfHLvZtf5SeTS-gvAcY_wAidXQ@mail.gmail.com>
 (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>
 <CAA6-MF-npREucdWneVw+DWMQi3bG+3zp98VNctErfLMuRkvY9A@mail.gmail.com>
 <87a5kjgw3j.fsf@ungleich.ch>
 <f292656a-52c8-4258-8b6a-45064a702a8a@keff.org>
 <874jarfd43.fsf@ungleich.ch>
 <CAC6SzHJFRNPsLNSd7_w8qQwtyfHLvZtf5SeTS-gvAcY_wAidXQ@mail.gmail.com>
Message-ID: <87bk4tc5m7.fsf@ungleich.ch>


d tbsky <tbskyd at gmail.com> 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: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20240526/480a7a66/attachment.sig>

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:
 <IRQ>
 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
 </IRQ>
 <TASK>
 __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
 </TASK>
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:
 <TASK>
 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
 </TASK>
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:
 <TASK>
 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:
 <TASK>
 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
 </TASK>
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:
 <TASK>
 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