From deller at kernel.org Wed Jul 3 16:20:19 2024 From: deller at kernel.org (Helge Deller) Date: Wed, 3 Jul 2024 18:20:19 +0200 Subject: [PATCH] wireguard: allowedips: Prevent unaligned memory accesses Message-ID: On the parisc platform the Linux kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc) Avoid such unaligned memory accesses by instead using the get_unaligned_be64() helper macro. Signed-off-by: Helge Deller diff --git a/drivers/net/wireguard/allowedips.c b/drivers/net/wireguard/allowedips.c index 0ba714ca5185..daf967130b72 100644 --- a/drivers/net/wireguard/allowedips.c +++ b/drivers/net/wireguard/allowedips.c @@ -15,8 +15,8 @@ static void swap_endian(u8 *dst, const u8 *src, u8 bits) if (bits == 32) { *(u32 *)dst = be32_to_cpu(*(const __be32 *)src); } else if (bits == 128) { - ((u64 *)dst)[0] = be64_to_cpu(((const __be64 *)src)[0]); - ((u64 *)dst)[1] = be64_to_cpu(((const __be64 *)src)[1]); + ((u64 *)dst)[0] = get_unaligned_be64(src); + ((u64 *)dst)[1] = get_unaligned_be64(src[8]); } } From Jason at zx2c4.com Wed Jul 3 18:11:14 2024 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 3 Jul 2024 20:11:14 +0200 Subject: [PATCH] wireguard: allowedips: Prevent unaligned memory accesses In-Reply-To: References: Message-ID: Hi Helge, On Wed, Jul 03, 2024 at 06:20:19PM +0200, Helge Deller wrote: > On the parisc platform the Linux kernel issues kernel warnings because > swap_endian() tries to load a 128-bit IPv6 address from an unaligned > memory location: > Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) > Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc) > > Avoid such unaligned memory accesses by instead using the > get_unaligned_be64() helper macro. > > Signed-off-by: Helge Deller > > diff --git a/drivers/net/wireguard/allowedips.c b/drivers/net/wireguard/allowedips.c > index 0ba714ca5185..daf967130b72 100644 > --- a/drivers/net/wireguard/allowedips.c > +++ b/drivers/net/wireguard/allowedips.c > @@ -15,8 +15,8 @@ static void swap_endian(u8 *dst, const u8 *src, u8 bits) > if (bits == 32) { > *(u32 *)dst = be32_to_cpu(*(const __be32 *)src); > } else if (bits == 128) { > - ((u64 *)dst)[0] = be64_to_cpu(((const __be64 *)src)[0]); > - ((u64 *)dst)[1] = be64_to_cpu(((const __be64 *)src)[1]); > + ((u64 *)dst)[0] = get_unaligned_be64(src); Ahh, right, in6_addr only has a u32 member, not a u64 member, so that's potentially unaligned. > + ((u64 *)dst)[1] = get_unaligned_be64(src[8]); src[8] is not correct, however. (This crashes; did you test it?) I've fixed it up and put it in the wireguard tree: https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/wireguard-linux.git/commit/?id=ad3d9eef8e1b304b243e63124581f97c88ce7ff9 I'll push this up to net.git soon. Thanks for the patch. Jason From syzbot+list3f44d498ace31a0c4fcf at syzkaller.appspotmail.com Thu Jul 4 07:49:25 2024 From: syzbot+list3f44d498ace31a0c4fcf at syzkaller.appspotmail.com (syzbot) Date: Thu, 04 Jul 2024 00:49:25 -0700 Subject: [syzbot] Monthly wireguard report (Jul 2024) Message-ID: <0000000000009059a6061c672f4d@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, 0 new issues were detected and 2 were fixed. In total, 8 issues are still open and 18 have been fixed so far. Some of the still happening issues: Ref Crashes Repro Title <1> 1009 No KCSAN: data-race in wg_packet_send_staged_packets / wg_packet_send_staged_packets (3) https://syzkaller.appspot.com/bug?extid=6ba34f16b98fe40daef1 <2> 59 No INFO: task hung in __tun_chr_ioctl (6) https://syzkaller.appspot.com/bug?extid=26c7b4c3afe5450b3e15 <3> 14 No WARNING in kthread_unpark (2) https://syzkaller.appspot.com/bug?extid=943d34fa3cf2191e3068 --- 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 r.sander at heinlein-support.de Tue Jul 9 08:23:10 2024 From: r.sander at heinlein-support.de (Robert Sander) Date: Tue, 9 Jul 2024 10:23:10 +0200 Subject: disable roaming? Message-ID: <5f5fe5f9-fa9d-4d11-a33f-9d7e326823f5@heinlein-support.de> Hi, I want to setup a wg tunnel between an office and a pair of routers which use keepalived for a service IP. The office router would have the service IP in its config. As soon as the IP failover happens between the two routers the office router gets a new peer address for its connection (which is not reachable). How do I disable the wireguard roaming on the server side? Wireguard on the office router should always connect to the service IP. Both routers have the same private/public key so that should be possible. Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Gesch?ftsf?hrer: Peer Heinlein - Sitz: Berlin From endre.szabo at wg-ml-rkaofgr.redir.email Tue Jul 9 09:51:51 2024 From: endre.szabo at wg-ml-rkaofgr.redir.email (Endre Szabo) Date: Tue, 9 Jul 2024 09:51:51 +0000 Subject: disable roaming? In-Reply-To: <5f5fe5f9-fa9d-4d11-a33f-9d7e326823f5@heinlein-support.de> References: <5f5fe5f9-fa9d-4d11-a33f-9d7e326823f5@heinlein-support.de> Message-ID: Sounds like these routers are multihomed, so it might be a perfect fit for use of a routing protocol. On Tue, Jul 09, 2024 at 10:23:10+0200, Robert Sander wrote: > Hi, > > I want to setup a wg tunnel between an office and a pair of routers which > use keepalived for a service IP. > > The office router would have the service IP in its config. > > As soon as the IP failover happens between the two routers the office router > gets a new peer address for its connection (which is not reachable). > > How do I disable the wireguard roaming on the server side? > > Wireguard on the office router should always connect to the service IP. > Both routers have the same private/public key so that should be possible. > > Regards > -- > Robert Sander > Heinlein Consulting GmbH > Schwedter Str. 8/9b, 10119 Berlin > > https://www.heinlein-support.de > > Tel: 030 / 405051-43 > Fax: 030 / 405051-19 > > Amtsgericht Berlin-Charlottenburg - HRB 220009 B > Gesch?ftsf?hrer: Peer Heinlein - Sitz: Berlin From vbabka at suse.cz Mon Jul 15 20:39:39 2024 From: vbabka at suse.cz (Vlastimil Babka) Date: Mon, 15 Jul 2024 20:39:39 -0000 Subject: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback In-Reply-To: References: <3b6fe525-626c-41fb-8625-3925ca820d8e@paulmck-laptop> <6711935d-20b5-41c1-8864-db3fc7d7823d@suse.cz> <36c60acd-543e-48c5-8bd2-6ed509972d28@suse.cz> <5c8b2883-962f-431f-b2d3-3632755de3b0@paulmck-laptop> <9967fdfa-e649-456d-a0cb-b4c4bf7f9d68@suse.cz> <6dad6e9f-e0ca-4446-be9c-1be25b2536dd@paulmck-laptop> <4cba4a48-902b-4fb6-895c-c8e6b64e0d5f@suse.cz> Message-ID: On 6/21/24 11:32 AM, Uladzislau Rezki wrote: > On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote: > One question. Maybe it is already late but it is better to ask rather than not. > > What do you think if we have a small discussion about it on the LPC 2024 as a > topic? It might be it is already late or a schedule is set by now. Or we fix > it by a conference time. > > Just a thought. Sorry for the late reply. The MM MC turned out to be so packed I didn't even propose a slab topic. We could discuss in hallway track or a BOF, but hopefully if the current direction taken by my RFC brings no unexpected surprise, and the necessary RCU barrier side is also feasible, this will be settled by time of plumbers. > -- > Uladzislau Rezki From paulmck at kernel.org Wed Jul 24 13:53:34 2024 From: paulmck at kernel.org (Paul E. McKenney) Date: Wed, 24 Jul 2024 06:53:34 -0700 Subject: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback In-Reply-To: References: <6711935d-20b5-41c1-8864-db3fc7d7823d@suse.cz> <36c60acd-543e-48c5-8bd2-6ed509972d28@suse.cz> <5c8b2883-962f-431f-b2d3-3632755de3b0@paulmck-laptop> <9967fdfa-e649-456d-a0cb-b4c4bf7f9d68@suse.cz> <6dad6e9f-e0ca-4446-be9c-1be25b2536dd@paulmck-laptop> <4cba4a48-902b-4fb6-895c-c8e6b64e0d5f@suse.cz>

Message-ID: On Mon, Jul 15, 2024 at 10:39:38PM +0200, Vlastimil Babka wrote: > On 6/21/24 11:32 AM, Uladzislau Rezki wrote: > > On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote: > > One question. Maybe it is already late but it is better to ask rather than not. > > > > What do you think if we have a small discussion about it on the LPC 2024 as a > > topic? It might be it is already late or a schedule is set by now. Or we fix > > it by a conference time. > > > > Just a thought. > > Sorry for the late reply. The MM MC turned out to be so packed I didn't even > propose a slab topic. We could discuss in hallway track or a BOF, but > hopefully if the current direction taken by my RFC brings no unexpected > surprise, and the necessary RCU barrier side is also feasible, this will be > settled by time of plumbers. That would be even better! Thanx, Paul From vbabka at suse.cz Wed Jul 24 14:40:41 2024 From: vbabka at suse.cz (Vlastimil Babka) Date: Wed, 24 Jul 2024 16:40:41 +0200 Subject: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback In-Reply-To: References: <6711935d-20b5-41c1-8864-db3fc7d7823d@suse.cz> <36c60acd-543e-48c5-8bd2-6ed509972d28@suse.cz> <5c8b2883-962f-431f-b2d3-3632755de3b0@paulmck-laptop> <9967fdfa-e649-456d-a0cb-b4c4bf7f9d68@suse.cz> <6dad6e9f-e0ca-4446-be9c-1be25b2536dd@paulmck-laptop> <4cba4a48-902b-4fb6-895c-c8e6b64e0d5f@suse.cz>

Message-ID: <38207d5c-c052-4701-8ccd-fe6381a97194@suse.cz> On 7/24/24 3:53 PM, Paul E. McKenney wrote: > On Mon, Jul 15, 2024 at 10:39:38PM +0200, Vlastimil Babka wrote: >> On 6/21/24 11:32 AM, Uladzislau Rezki wrote: >> > On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote: >> > One question. Maybe it is already late but it is better to ask rather than not. >> > >> > What do you think if we have a small discussion about it on the LPC 2024 as a >> > topic? It might be it is already late or a schedule is set by now. Or we fix >> > it by a conference time. >> > >> > Just a thought. >> >> Sorry for the late reply. The MM MC turned out to be so packed I didn't even >> propose a slab topic. We could discuss in hallway track or a BOF, but >> hopefully if the current direction taken by my RFC brings no unexpected >> surprise, and the necessary RCU barrier side is also feasible, this will be >> settled by time of plumbers. > > That would be even better! I should have linked to the RFC :) https://lore.kernel.org/all/20240715-b4-slab-kfree_rcu-destroy-v1-0-46b2984c2205 at suse.cz/ From otilibil at eurecom.fr Thu Jul 25 20:42:37 2024 From: otilibil at eurecom.fr (Ariel Otilibili) Date: Thu, 25 Jul 2024 22:42:37 +0200 Subject: Extracted error message for the sake of legibility Message-ID: <20240725204917.192647-2-otilibil@eurecom.fr> Hello, I have been using WireGuard for some time; it does ease the configuration of VPNs. This is my first patch to the list, I asked to be subscribed; please confirm me it is the case. I would like to improve my C programming skills; your feedback will be much appreciated. Ariel From otilibil at eurecom.fr Thu Jul 25 20:42:38 2024 From: otilibil at eurecom.fr (Ariel Otilibili) Date: Thu, 25 Jul 2024 22:42:38 +0200 Subject: [PATCH] Extracted error message for the sake of legibility In-Reply-To: <20240725204917.192647-2-otilibil@eurecom.fr> References: <20240725204917.192647-2-otilibil@eurecom.fr> Message-ID: <20240725204917.192647-3-otilibil@eurecom.fr> Signed-off-by: Ariel Otilibili --- src/set.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/set.c b/src/set.c index 75560fd..b2fbd54 100644 --- a/src/set.c +++ b/src/set.c @@ -16,9 +16,19 @@ int set_main(int argc, const char *argv[]) { struct wgdevice *device = NULL; int ret = 1; + const char *error_message = "Usage: %s %s " + " [listen-port ]" + " [fwmark ]" + " [private-key ]" + " [peer [remove]" + " [preshared-key ]" + " [endpoint :]" + " [persistent-keepalive ]" + " [allowed-ips /[,/]...]" + " ]...\n"; if (argc < 3) { - fprintf(stderr, "Usage: %s %s [listen-port ] [fwmark ] [private-key ] [peer [remove] [preshared-key ] [endpoint :] [persistent-keepalive ] [allowed-ips /[,/]...] ]...\n", PROG_NAME, argv[0]); + fprintf(stderr, error_message, PROG_NAME, argv[0]); return 1; } -- 2.45.2 From syzbot+943d34fa3cf2191e3068 at syzkaller.appspotmail.com Mon Jul 29 15:48:30 2024 From: syzbot+943d34fa3cf2191e3068 at syzkaller.appspotmail.com (syzbot) Date: Mon, 29 Jul 2024 08:48:30 -0700 Subject: [syzbot] [wireguard?] WARNING in kthread_unpark (2) In-Reply-To: <00000000000061c0a106183499ec@google.com> Message-ID: <000000000000e9a538061e64cae7@google.com> syzbot has found a reproducer for the following issue on: HEAD commit: dc1c8034e31b minmax: simplify min()/max()/clamp() implemen.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=100341c9980000 kernel config: https://syzkaller.appspot.com/x/.config?x=2258b49cd9b339fa dashboard link: https://syzkaller.appspot.com/bug?extid=943d34fa3cf2191e3068 compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1022b573980000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/6699621c3baa/disk-dc1c8034.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/22380dec726f/vmlinux-dc1c8034.xz kernel image: https://storage.googleapis.com/syzbot-assets/04c3f45e6e2d/bzImage-dc1c8034.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: 53 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 [inline] WARNING: CPU: 0 PID: 53 at kernel/kthread.c:525 __kthread_bind kernel/kthread.c:538 [inline] WARNING: CPU: 0 PID: 53 at kernel/kthread.c:525 kthread_unpark+0x16b/0x210 kernel/kthread.c:631 Modules linked in: CPU: 0 UID: 0 PID: 53 Comm: kworker/u8:3 Not tainted 6.11.0-rc1-syzkaller-00004-gdc1c8034e31b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/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 ad f7 56 0a eb 09 e8 06 a0 33 00 90 <0f> 0b 90 48 89 ef be 08 00 00 00 e8 c5 b5 97 00 f0 80 65 00 fb 4c RSP: 0018:ffffc90000bd7760 EFLAGS: 00010293 RAX: ffffffff815fe27a RBX: 0000000000000000 RCX: ffff888015f90000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88801fcd8200 R08: ffffffff815fe207 R09: 1ffffffff269d71e R10: dffffc0000000000 R11: fffffbfff269d71f R12: 0000000000000001 R13: ffff888029c75a2c R14: 1ffff1100538eb45 R15: ffff888029c75a00 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc23f437d60 CR3: 000000007e72a000 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:5793 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10753 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11889 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/0xd40 kernel/workqueue.c:3390 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 --- If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing.