amnezia-vpn/amneziawg-linux-kernel-module
1
0
Fork 0
mirror of https://github.com/amnezia-vpn/amneziawg-linux-kernel-module.git synced 2026-10-14 05:41:56 +00:00
Code Issues 131 Projects Packages Wiki Activity

[PR #153] [MERGED] fix: memory corruption in jp_spec_setup causing kernel crash #207

New issue
Closed
opened 2026-10-13 21:07:38 +00:00 by bsakaguchi · 0 comments
bsakaguchi commented 2026-10-13 21:07:38 +00:00
Owner
Copy link

📋 Pull Request Information

Original PR: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/pull/153
Author: @Arsolitt
Created: 3/18/2026
Status: ✅ Merged
Merged: 3/29/2026
Merged by: @pokamest

Base: master ← Head: fix-memory-corruption-ispecs

📝 Commits (2)

  • a860536 fix: memory corruption in jp_spec_setup causing kernel crash
  • 7ffa57b fix: race condition in jp_spec_setup causing use-after-free

📊 Changes

3 files changed (+25 additions, -6 deletions)

View changed files

📝 src/device.c (+3 -1)
📝 src/junk.c (+17 -5)
📝 src/netlink.c (+5 -0)

📄 Description

Problem

When I1-I5 parameters are configured, the kernel module crashes with a kernel oops. The bug was reproduced on CachyOS with kernels:

  • 6.18.17-1-cachyos-lts
  • 6.19.7-1-cachyos
  • 6.18.17-1-cachyos-hardened

Crash can be triggered more quickly by restarting awg-quick several times in rapid succession. The bug does not occur with the userspace implementation — only the kernel module is affected.

Kernel Log (journalctl)

20:49:05 chachad kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
20:49:05 chachad kernel: BUG: unable to handle page fault for address: ffff8dc10b6cfd80
20:49:05 chachad kernel: #PF: supervisor instruction fetch in kernel mode
20:49:05 chachad kernel: #PF: error_code(0x0011) - permissions violation
20:49:05 chachad kernel: Oops: Oops: 0011 [#1] SMP NOPTI
20:49:05 chachad kernel: CPU: 2 UID: 0 PID: 23147 Comm: kworker/u64:7 Tainted: G            E       6.19.7-1-cachyos #1 PREEMPT(full)  15e23aa12dd47ccea83e8d73284b613cff5d9fe3
20:49:05 chachad kernel: Tainted: [E]=UNSIGNED_MODULE
20:49:05 chachad kernel: Hardware name: Gigabyte Technology Co., Ltd. Z590 D/Z590 D, BIOS F7 04/14/2022
20:49:05 chachad kernel: Workqueue: wg-kex-awg0 wg_packet_handshake_send_worker [amneziawg]
20:49:05 chachad kernel: RIP: 0010:0xffff8dc10b6cfd80
20:49:05 chachad kernel: Code: ff ff 50 fd 6c 0b c1 8d ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> e0 49 44 c1 8d ff ff 00 bc dd f6 c0 8d ff ff 00 00 00 00 00 00
20:49:05 chachad kernel: RSP: 0018:ffffd08f87633d28 EFLAGS: 00010282
20:49:05 chachad kernel: RAX: 0000000000000006 RBX: ffff8dc5943026d0 RCX: ffff8dc0c5d9ff00
20:49:05 chachad kernel: RDX: ffff8dc5943026d0 RSI: 000000000b6cfdd0 RDI: ffff8dc10b6cfdd0
20:49:05 chachad kernel: RBP: ffff8dc34d81ea80 R08: 00000000009c432a R09: 0000000000000004
20:49:05 chachad kernel: R10: ffffd08f87633d64 R11: ffff8dc10b6cfd80 R12: 0000000000000004
20:49:05 chachad kernel: R13: ffff8dc594302918 R14: ffff8dc34d81ef98 R15: 0000000000000070
20:49:05 chachad kernel: FS:  0000000000000000(0000) GS:ffff8dc8c4556000(0000) knlGS:0000000000000000
20:49:05 chachad kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
20:49:05 chachad kernel: CR2: ffff8dc10b6cfd80 CR3: 000000026a50c001 CR4: 0000000000772ef0
20:49:05 chachad kernel: PKRU: 55555554
20:49:05 chachad kernel: Call Trace:
20:49:05 chachad kernel:  <TASK>
20:49:05 chachad kernel:  ? jp_spec_applymods+0x5f/0x80 [amneziawg fb41c277fb6c10e2fa3cb023e201e5378362364e]
20:49:05 chachad kernel:  ? wg_packet_handshake_send_worker+0xbb/0x430 [amneziawg fb41c277fb6c10e2fa3cb023e201e5378362364e]
20:49:05 chachad kernel:  ? process_scheduled_works+0x24c/0x5f0
20:49:05 chachad kernel:  ? worker_thread+0x18e/0x340
20:49:05 chachad kernel:  ? __pfx_worker_thread+0x10/0x10
20:49:05 chachad kernel:  ? kthread+0x217/0x250
20:49:05 chachad kernel:  ? __pfx_kthread+0x10/0x10
20:49:05 chachad kernel:  ? ret_from_fork+0x10e/0x260
20:49:05 chachad kernel:  ? __pfx_kthread+0x10/0x10
20:49:05 chachad kernel:  ? ret_from_fork_asm+0x1a/0x30
20:49:05 chachad kernel:  </TASK>
20:49:05 chachad kernel: Modules linked in: uinput rfcomm snd_seq_dummy snd_hrtimer snd_seq cfg80211 nft_fib_ipv4 nft_fib nft_masq nft_ct wireguard veth nf_conntrack_netlink xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE bridge stp llc xfrm_user xfrm_algo xt_set ip_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 x>
20:49:05 chachad kernel:  crc8 snd_hda_codec_generic snd_hda_codec_atihdnn snd_soc_avs snd_hda_codec_hdmi kvm_intel snd_soc_hda_codec snd_hda_ext_core snd_hda_intel snd_usb_audio kvm snd_hda_codec snd_usbmidi_lib snd_hda_core snd_soc_core btusb snd_ump btmtk snd_intel_dspcfg_task r8169 ac97_bus snd_rawmidi irqbypass snd_intel_sdw_acpi >
20:49:05 chachad kernel:  amdgpu drm_panel_backlight_quirks drm_buddy drm_suballoc_helper drm_exec i2c_algo_bit gpu_sched amdxcp drm_ttm_helper ttm nvme drm_display_helper ghash_clmulni_intel nvme_core aesni_intel cec nvme_keyring video spi_intel_pci nvme_auth spi_intel hkdf wmi hid_logitech_dj
20:49:05 chachad kernel: CR2: ffff8dc10b6cfd80
20:49:05 chachad kernel: RIP: 0010:0xffff8dc10b6cfd80
20:49:05 chachad kernel: Code: ff ff 50 fd 6c 0b c1 8d ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> e0 49 44 c1 8d ff ff 00 bc dd f6 c0 8d ff ff 00 00 00 00 00 00
20:49:05 chachad kernel: RSP: 0018:ffffd08f87633d28 EFLAGS: 00010282
20:49:05 chachad kernel: RAX: 0000000000000006 RBX: ffff8dc5943026d0 RCX: ffff8dc0c5d9ff00
20:49:05 chachad kernel: RDX: ffff8dc5943026d0 RSI: 000000000b6cfdd0 RDI: ffff8dc10b6cfdd0
20:49:05 chachad kernel: RBP: ffff8dc34d81ea80 R08: 00000000009c432a R09: 0000000000000004
20:49:05 chachad kernel: R10: ffffd08f87633d64 R11: ffff8dc10b6cfd80 R12: 0000000000000004
20:49:05 chachad kernel: R13: ffff8dc594302918 R14: ffff8dc34d81ef98 R15: 0000000000000070
20:49:05 chachad kernel: FS:  0000000000000000(0000) GS:ffff8dc8c4556000(0000) knlGS:0000000000000000
20:49:05 chachad kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
20:49:05 chachad kernel: CR2: ffff8dc10b6cfd80 CR3: 000000026a50c001 CR4: 0000000000772ef0
20:49:05 chachad kernel: PKRU: 55555554

Root Cause Analysis

Bug 1: Out-of-bounds write (causes immediate crash)

In src/junk.c:jp_spec_setup():

  • spec->pkt_size was reset to 0 before the fill loop
  • spec->mods_size was NOT reset to 0

This causes memory corruption on subsequent configurations:

  1. First config: spec->mods_size = 3, array allocated, filled correctly
  2. Second config: local mods_size = 2, new array allocated with size 2
  3. But spec->mods_size still = 3 from previous run
  4. Fill loop writes at spec->mods + spec->mods_size = index 3, 4, 5... (out of bounds!)
  5. Garbage overwrites adjacent memory, including function pointers
  6. jp_spec_applymods() calls mod->func() → jumps to garbage address → NX page fault

Bug 2: Race condition causing use-after-free

Fixed in second commit (d367e96)

mutex_init(&spec->lock) was called in jp_spec_setup() on every configuration change. This re-initializes the mutex while it may be locked by another thread:

  1. send.c holds spec->lock, uses spec->pkt
  2. jp_spec_setup (config reload) calls mutex_init(&spec->lock) — re-inits locked mutex!
  3. Mutex is now in broken state, mutex_lock succeeds immediately
  4. jp_spec_setup does kfree(spec->pkt) while send.c still uses it
  5. Use-after-free → crash

The fix: Initialize mutexes once in wg_newlink() during device creation, not in jp_spec_setup().

Bug 3: Memory leaks

  • Old spec->pkt, spec->mods not freed before reallocation in jp_spec_setup()
  • Old spec->desc not freed before reallocation in netlink.c
  • jp_spec_free() didn't free spec->desc

Fix Summary

Commit Location Change
e5bc9a3 junk.c:jp_spec_setup() Free old pkt/mods, reset mods_size = 0 before fill loop
e5bc9a3 netlink.c kfree(desc) before assigning new value
e5bc9a3 junk.c:jp_spec_free() Free desc, null all pointers, reset counters
d367e96 device.c:wg_newlink() Initialize ispecs[i].lock mutexes once at device creation
d367e96 junk.c:jp_spec_setup() Remove mutex_init(&spec->lock) — mutex already initialized

Testing

Tested with various I1-I5 configurations:

I1 = <rd 12><rd 26><r 28>
I2 = <t><rd 14><b 0x1ef394dae1c6398a0bca>
I3 = <t><b 0x8c3ccc695332edafc52b><b 0x12c7ac72ca4ceb69845d070856><rc 28><rd 19><r 27>
I4 = <rd 13><b 0xabcaa60aa65a8ef5a2><r 5><rc 6><b 0xa7e7068a5fa576487022c823f0fcbef2>
I5 = <t><rd 24><b 0x92b6fdcb0faa1ef9a8c9><b 0xa50ee2c38b61><rc 27>

I1 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0040><b 0x00><b 0x01><t><r 40>
I2 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0020><b 0x01><t><r 20>
I3 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0010><b 0x01><t><r 10>
I4 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0005><b 0x01><t><r 5>
  • Before fix: immediate kernel crash, sometimes takes AMD GPU driver down with it
  • After fix: stable operation, rapid awg-quick restarts work correctly

this PR fixes:

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/pull/153 **Author:** [@Arsolitt](https://github.com/Arsolitt) **Created:** 3/18/2026 **Status:** ✅ Merged **Merged:** 3/29/2026 **Merged by:** [@pokamest](https://github.com/pokamest) **Base:** `master` ← **Head:** `fix-memory-corruption-ispecs` --- ### 📝 Commits (2) - [`a860536`](https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/commit/a86053641c3221064c2d3667fda628c9d2d392be) fix: memory corruption in jp_spec_setup causing kernel crash - [`7ffa57b`](https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/commit/7ffa57bcc2f41b474441367bf2d913850641a06e) fix: race condition in jp_spec_setup causing use-after-free ### 📊 Changes **3 files changed** (+25 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `src/device.c` (+3 -1) 📝 `src/junk.c` (+17 -5) 📝 `src/netlink.c` (+5 -0) </details> ### 📄 Description ## Problem When I1-I5 parameters are configured, the kernel module crashes with a kernel oops. The bug was reproduced on CachyOS with kernels: - 6.18.17-1-cachyos-lts - 6.19.7-1-cachyos - 6.18.17-1-cachyos-hardened Crash can be triggered more quickly by restarting `awg-quick` several times in rapid succession. The bug **does not occur** with the userspace implementation — only the kernel module is affected. ### Kernel Log (journalctl) ``` 20:49:05 chachad kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) 20:49:05 chachad kernel: BUG: unable to handle page fault for address: ffff8dc10b6cfd80 20:49:05 chachad kernel: #PF: supervisor instruction fetch in kernel mode 20:49:05 chachad kernel: #PF: error_code(0x0011) - permissions violation 20:49:05 chachad kernel: Oops: Oops: 0011 [#1] SMP NOPTI 20:49:05 chachad kernel: CPU: 2 UID: 0 PID: 23147 Comm: kworker/u64:7 Tainted: G E 6.19.7-1-cachyos #1 PREEMPT(full) 15e23aa12dd47ccea83e8d73284b613cff5d9fe3 20:49:05 chachad kernel: Tainted: [E]=UNSIGNED_MODULE 20:49:05 chachad kernel: Hardware name: Gigabyte Technology Co., Ltd. Z590 D/Z590 D, BIOS F7 04/14/2022 20:49:05 chachad kernel: Workqueue: wg-kex-awg0 wg_packet_handshake_send_worker [amneziawg] 20:49:05 chachad kernel: RIP: 0010:0xffff8dc10b6cfd80 20:49:05 chachad kernel: Code: ff ff 50 fd 6c 0b c1 8d ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> e0 49 44 c1 8d ff ff 00 bc dd f6 c0 8d ff ff 00 00 00 00 00 00 20:49:05 chachad kernel: RSP: 0018:ffffd08f87633d28 EFLAGS: 00010282 20:49:05 chachad kernel: RAX: 0000000000000006 RBX: ffff8dc5943026d0 RCX: ffff8dc0c5d9ff00 20:49:05 chachad kernel: RDX: ffff8dc5943026d0 RSI: 000000000b6cfdd0 RDI: ffff8dc10b6cfdd0 20:49:05 chachad kernel: RBP: ffff8dc34d81ea80 R08: 00000000009c432a R09: 0000000000000004 20:49:05 chachad kernel: R10: ffffd08f87633d64 R11: ffff8dc10b6cfd80 R12: 0000000000000004 20:49:05 chachad kernel: R13: ffff8dc594302918 R14: ffff8dc34d81ef98 R15: 0000000000000070 20:49:05 chachad kernel: FS: 0000000000000000(0000) GS:ffff8dc8c4556000(0000) knlGS:0000000000000000 20:49:05 chachad kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20:49:05 chachad kernel: CR2: ffff8dc10b6cfd80 CR3: 000000026a50c001 CR4: 0000000000772ef0 20:49:05 chachad kernel: PKRU: 55555554 20:49:05 chachad kernel: Call Trace: 20:49:05 chachad kernel: <TASK> 20:49:05 chachad kernel: ? jp_spec_applymods+0x5f/0x80 [amneziawg fb41c277fb6c10e2fa3cb023e201e5378362364e] 20:49:05 chachad kernel: ? wg_packet_handshake_send_worker+0xbb/0x430 [amneziawg fb41c277fb6c10e2fa3cb023e201e5378362364e] 20:49:05 chachad kernel: ? process_scheduled_works+0x24c/0x5f0 20:49:05 chachad kernel: ? worker_thread+0x18e/0x340 20:49:05 chachad kernel: ? __pfx_worker_thread+0x10/0x10 20:49:05 chachad kernel: ? kthread+0x217/0x250 20:49:05 chachad kernel: ? __pfx_kthread+0x10/0x10 20:49:05 chachad kernel: ? ret_from_fork+0x10e/0x260 20:49:05 chachad kernel: ? __pfx_kthread+0x10/0x10 20:49:05 chachad kernel: ? ret_from_fork_asm+0x1a/0x30 20:49:05 chachad kernel: </TASK> 20:49:05 chachad kernel: Modules linked in: uinput rfcomm snd_seq_dummy snd_hrtimer snd_seq cfg80211 nft_fib_ipv4 nft_fib nft_masq nft_ct wireguard veth nf_conntrack_netlink xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE bridge stp llc xfrm_user xfrm_algo xt_set ip_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 x> 20:49:05 chachad kernel: crc8 snd_hda_codec_generic snd_hda_codec_atihdnn snd_soc_avs snd_hda_codec_hdmi kvm_intel snd_soc_hda_codec snd_hda_ext_core snd_hda_intel snd_usb_audio kvm snd_hda_codec snd_usbmidi_lib snd_hda_core snd_soc_core btusb snd_ump btmtk snd_intel_dspcfg_task r8169 ac97_bus snd_rawmidi irqbypass snd_intel_sdw_acpi > 20:49:05 chachad kernel: amdgpu drm_panel_backlight_quirks drm_buddy drm_suballoc_helper drm_exec i2c_algo_bit gpu_sched amdxcp drm_ttm_helper ttm nvme drm_display_helper ghash_clmulni_intel nvme_core aesni_intel cec nvme_keyring video spi_intel_pci nvme_auth spi_intel hkdf wmi hid_logitech_dj 20:49:05 chachad kernel: CR2: ffff8dc10b6cfd80 20:49:05 chachad kernel: RIP: 0010:0xffff8dc10b6cfd80 20:49:05 chachad kernel: Code: ff ff 50 fd 6c 0b c1 8d ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> e0 49 44 c1 8d ff ff 00 bc dd f6 c0 8d ff ff 00 00 00 00 00 00 20:49:05 chachad kernel: RSP: 0018:ffffd08f87633d28 EFLAGS: 00010282 20:49:05 chachad kernel: RAX: 0000000000000006 RBX: ffff8dc5943026d0 RCX: ffff8dc0c5d9ff00 20:49:05 chachad kernel: RDX: ffff8dc5943026d0 RSI: 000000000b6cfdd0 RDI: ffff8dc10b6cfdd0 20:49:05 chachad kernel: RBP: ffff8dc34d81ea80 R08: 00000000009c432a R09: 0000000000000004 20:49:05 chachad kernel: R10: ffffd08f87633d64 R11: ffff8dc10b6cfd80 R12: 0000000000000004 20:49:05 chachad kernel: R13: ffff8dc594302918 R14: ffff8dc34d81ef98 R15: 0000000000000070 20:49:05 chachad kernel: FS: 0000000000000000(0000) GS:ffff8dc8c4556000(0000) knlGS:0000000000000000 20:49:05 chachad kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20:49:05 chachad kernel: CR2: ffff8dc10b6cfd80 CR3: 000000026a50c001 CR4: 0000000000772ef0 20:49:05 chachad kernel: PKRU: 55555554 ``` ## Root Cause Analysis ### Bug 1: Out-of-bounds write (causes immediate crash) In `src/junk.c:jp_spec_setup()`: - `spec->pkt_size` was reset to 0 before the fill loop - **`spec->mods_size` was NOT reset to 0** This causes memory corruption on subsequent configurations: 1. First config: `spec->mods_size` = 3, array allocated, filled correctly 2. Second config: local `mods_size` = 2, new array allocated with size 2 3. But `spec->mods_size` still = 3 from previous run 4. Fill loop writes at `spec->mods + spec->mods_size` = index 3, 4, 5... (out of bounds!) 5. Garbage overwrites adjacent memory, including function pointers 6. `jp_spec_applymods()` calls `mod->func()` → jumps to garbage address → NX page fault ### Bug 2: Race condition causing use-after-free **Fixed in second commit (d367e96)** `mutex_init(&spec->lock)` was called in `jp_spec_setup()` on every configuration change. This re-initializes the mutex while it may be locked by another thread: 1. `send.c` holds `spec->lock`, uses `spec->pkt` 2. `jp_spec_setup` (config reload) calls `mutex_init(&spec->lock)` — **re-inits locked mutex!** 3. Mutex is now in broken state, `mutex_lock` succeeds immediately 4. `jp_spec_setup` does `kfree(spec->pkt)` while `send.c` still uses it 5. **Use-after-free → crash** The fix: Initialize mutexes once in `wg_newlink()` during device creation, not in `jp_spec_setup()`. ### Bug 3: Memory leaks - Old `spec->pkt`, `spec->mods` not freed before reallocation in `jp_spec_setup()` - Old `spec->desc` not freed before reallocation in `netlink.c` - `jp_spec_free()` didn't free `spec->desc` ## Fix Summary | Commit | Location | Change | |--------|----------|--------| | e5bc9a3 | `junk.c:jp_spec_setup()` | Free old `pkt`/`mods`, reset `mods_size = 0` before fill loop | | e5bc9a3 | `netlink.c` | `kfree(desc)` before assigning new value | | e5bc9a3 | `junk.c:jp_spec_free()` | Free `desc`, null all pointers, reset counters | | d367e96 | `device.c:wg_newlink()` | Initialize `ispecs[i].lock` mutexes once at device creation | | d367e96 | `junk.c:jp_spec_setup()` | Remove `mutex_init(&spec->lock)` — mutex already initialized | ## Testing Tested with various I1-I5 configurations: ``` I1 = <rd 12><rd 26><r 28> I2 = <t><rd 14><b 0x1ef394dae1c6398a0bca> I3 = <t><b 0x8c3ccc695332edafc52b><b 0x12c7ac72ca4ceb69845d070856><rc 28><rd 19><r 27> I4 = <rd 13><b 0xabcaa60aa65a8ef5a2><r 5><rc 6><b 0xa7e7068a5fa576487022c823f0fcbef2> I5 = <t><rd 24><b 0x92b6fdcb0faa1ef9a8c9><b 0xa50ee2c38b61><rc 27> I1 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0040><b 0x00><b 0x01><t><r 40> I2 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0020><b 0x01><t><r 20> I3 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0010><b 0x01><t><r 10> I4 = <b 0xc0ff><b 0x00000001><b 0x08><r 8><b 0x00><b 0x00><b 0x0005><b 0x01><t><r 5> ``` - **Before fix:** immediate kernel crash, sometimes takes AMD GPU driver down with it - **After fix:** stable operation, rapid `awg-quick` restarts work correctly this PR fixes: - https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/102 - https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/139 - https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/140 - https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/154 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-13 21:07:38 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/awg4
build/newer-ubuntu
v3.1.20260906
v3.1.20260828
v3.1.20260827
v3.1.20260812
v3.0.20260805
v3.0.20260731-04
v3.0.20260731-03
v3.0.20260731-02
v3.0.20260731
v3.0.20260730
v1.0.20260725
v1.0.20260611
v1.0.20260329-2
v1.0.20260329
v1.0.20260322
v1.0.20260210
v1.0.20251104
v1.0.20251009
v1.0.20251004
v1.0.20241112
v1.0.20241023
v1.0.20241022
v1.0.20240711
v1.0.20240213
v1.0.20240207
v1.0.20220627
v1.0.20211208
v1.0.20210606
v1.0.20210424
v1.0.20210219
v1.0.20210124
v1.0.20201221
v1.0.20201112
v1.0.20200908
v1.0.20200729
v1.0.20200712
v1.0.20200623
v1.0.20200611
v1.0.20200520
v1.0.20200506
v1.0.20200429
v1.0.20200426
v1.0.20200413
v1.0.20200401
v1.0.20200330
v0.0.20200318
v0.0.20200215
v0.0.20200214
v0.0.20200205
v0.0.20200128
v0.0.20200121
v0.0.20200105
v0.0.20191226
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
amnezia-vpn/amneziawg-linux-kernel-module#207
No description provided.