amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-15 05:42:07 +00:00

[GH-ISSUE #2781] Kernel panic m_copym_with_hdrs … copy overflow (uipc_mbuf.c:3268) on macOS 26.5.1 / Apple Silicon with an active AmneziaWG tunnel #1266

New issue

Open

opened 2026-10-13 20:39:11 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-13 20:39:11 +00:00

Owner

Originally created by @Metatau on GitHub (Jun 28, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2781

Summary

Hard kernel panic + watchdog reset on macOS 26.5.1 (Apple Silicon, M4 Pro) while an AmneziaWG packet-tunnel was active. The panic is in the XNU networking stack (mbuf copy with header), and it fired while SMB / large-segment TCP traffic was flowing through the tunnel. The kernel's own integrity check caught a malformed mbuf chain (packet-header length > actual chain length) and panicked instead of overflowing kernel memory.

Environment

┌────────────────┬─────────────────────────────────────────────────────────────────────────────┐
│ │ │
├────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ AmneziaWG for │ 2.0.2 (build 13) │
│ macOS │ │
├────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ macOS │ 26.5.1 (25F80) │
├────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Hardware │ Mac mini Mac16,11, Apple M4 Pro (SoC T6041), 14 cores │
├────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Kernel │ Darwin 25.5.0, xnu-12377.121.6~2/RELEASE_ARM64_T6041 │
├────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Secure boot │ YES │
├────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Active tunnel │ AmneziaWG split-tunnel, [Interface] MTU = 1420, default route + large │
│ │ allowed-IPs / geo-routing table through utunN │
├────────────────┼─────────────────────────────────────────────────────────────────────────────┤
│ Obfuscation │ Jc=<…>, Jmin=<…>, Jmax=<…>, S1=<…>, S2=<…>, H1=<…>, H2=<…>, H3=<…>, H4=<…> │
│ params │ ← fill from tunnel config (no private keys) │
└────────────────┴─────────────────────────────────────────────────────────────────────────────┘

Panic signature

panic(cpu 2 caller 0xfffffe005203fc60): m_copym_with_hdrs n 0xfffffe32fc142c00 copy overflow @uipc_mbuf.c:3268

Panicked task: kernel_task (pid 0), 688 threads
Reset type: watchdog (Boot faults: wdog, reset_in_1)
Paniclog version: 15

Backtrace (panicked thread, tid 5583)

lr: 0xfffffe0051a3e1ac fp: 0xfffffec0f169b320
lr: 0xfffffe0051bbf994 fp: 0xfffffec0f169b390
lr: 0xfffffe0051bbd928 fp: 0xfffffec0f169b450
lr: 0xfffffe00519ede9c fp: 0xfffffec0f169b460
lr: 0xfffffe0051a3e4bc fp: 0xfffffec0f169b980
lr: 0xfffffe0052333fa0 fp: 0xfffffec0f169b9a0
lr: 0xfffffe005203fc60 fp: 0xfffffec0f169ba50 <-- m_copym_with_hdrs (panic caller)
lr: 0xfffffe0051e82230 fp: 0xfffffec0f169bcf0
lr: 0xfffffe0051e91e24 fp: 0xfffffec0f169bd40
lr: 0xfffffe0051e93dd4 fp: 0xfffffec0f169bde0
lr: 0xfffffe0051aa8448 fp: 0xfffffec0f169be20
lr: 0xfffffe0051aa9458 fp: 0xfffffec0f169bf20
lr: 0xfffffe00519eeb6c fp: 0x0000000000000000
(Full symbolicated stackshot is in the attached panic log.)

Context / what was happening

The AmneziaWG split-tunnel was the active default route, with a large allowed-IPs table routed through the utun interface.
Immediately before the panic, an SMB share was mounted — last started kext at 19272083363: com.apple.filesystems.smbfs 6.0.1. In my case this was Google Drive File Stream (it mounts via SMB) syncing through the tunnel, i.e. large TCP segments being pushed through the tunnel.
m_copym_with_hdrs … copy overflow is XNU asserting that the mbuf packet header length (pkthdr.len) exceeds the summed length of the mbuf chain — i.e. a packet whose declared length is inconsistent with its actual buffer chain was handed to / re-injected into the network stack and then copied (TCP output / segmentation path).

Why I suspect the AmneziaWG provider

The panic is purely in the network mbuf path, and the only active tunnel was AmneziaWG.
AmneziaWG deliberately modifies packet sizes (junk packets + header obfuscation Jc/Jmin/Jmax/S1/S2/H1–H4). Resizing/rebuilding packets is a classic source of pkthdr.len ↔ mbuf-chain-length mismatch when packets are re-injected via NEPacketTunnelProvider.
Prior art: WireGuard tunnels are known to be able to trigger mbuf panics (e.g. OpenBSD "read-only mbuf passed" reports). The obfuscation layer plausibly widens this window.

Frequency

First observed occurrence (1 hard panic so far). Same day, preceding signs of stack instability: an AmneziaWG/WireGuard GUI crash on launch and a shutdown_stall.

Attached

awg-kernel-panic-2026-06-28.log — full kernel panic log with stackshot.

Request

Please review how the macOS packet-tunnel provider sets the mbuf packet-header length when rebuilding/re-injecting obfuscated or resized packets — particularly under SMB / large-segment TCP and split-tunnel routing with many routes. If pkthdr.len can diverge from the actual mbuf chain length after junk/obfuscation processing, that would explain the m_copym_with_hdrs overflow. Happy to provide more logs, exact obfuscation parameters, or test a patched build.

Originally created by @Metatau on GitHub (Jun 28, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2781 Summary Hard kernel panic + watchdog reset on macOS 26.5.1 (Apple Silicon, M4 Pro) while an AmneziaWG packet-tunnel was active. The panic is in the XNU networking stack (mbuf copy with header), and it fired while SMB / large-segment TCP traffic was flowing through the tunnel. The kernel's own integrity check caught a malformed mbuf chain (packet-header length > actual chain length) and panicked instead of overflowing kernel memory. Environment ┌────────────────┬─────────────────────────────────────────────────────────────────────────────┐ │ │ │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────┤ │ AmneziaWG for │ 2.0.2 (build 13) │ │ macOS │ │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────┤ │ macOS │ 26.5.1 (25F80) │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────┤ │ Hardware │ Mac mini Mac16,11, Apple M4 Pro (SoC T6041), 14 cores │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────┤ │ Kernel │ Darwin 25.5.0, xnu-12377.121.6~2/RELEASE_ARM64_T6041 │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────┤ │ Secure boot │ YES │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────┤ │ Active tunnel │ AmneziaWG split-tunnel, [Interface] MTU = 1420, default route + large │ │ │ allowed-IPs / geo-routing table through utunN │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────┤ │ Obfuscation │ Jc=<…>, Jmin=<…>, Jmax=<…>, S1=<…>, S2=<…>, H1=<…>, H2=<…>, H3=<…>, H4=<…> │ │ params │ ← fill from tunnel config (no private keys) │ └────────────────┴─────────────────────────────────────────────────────────────────────────────┘ Panic signature panic(cpu 2 caller 0xfffffe005203fc60): m_copym_with_hdrs n 0xfffffe32fc142c00 copy overflow @uipc_mbuf.c:3268 - Panicked task: kernel_task (pid 0), 688 threads - Reset type: watchdog (Boot faults: wdog, reset_in_1) - Paniclog version: 15 Backtrace (panicked thread, tid 5583) lr: 0xfffffe0051a3e1ac fp: 0xfffffec0f169b320 lr: 0xfffffe0051bbf994 fp: 0xfffffec0f169b390 lr: 0xfffffe0051bbd928 fp: 0xfffffec0f169b450 lr: 0xfffffe00519ede9c fp: 0xfffffec0f169b460 lr: 0xfffffe0051a3e4bc fp: 0xfffffec0f169b980 lr: 0xfffffe0052333fa0 fp: 0xfffffec0f169b9a0 lr: 0xfffffe005203fc60 fp: 0xfffffec0f169ba50 <-- m_copym_with_hdrs (panic caller) lr: 0xfffffe0051e82230 fp: 0xfffffec0f169bcf0 lr: 0xfffffe0051e91e24 fp: 0xfffffec0f169bd40 lr: 0xfffffe0051e93dd4 fp: 0xfffffec0f169bde0 lr: 0xfffffe0051aa8448 fp: 0xfffffec0f169be20 lr: 0xfffffe0051aa9458 fp: 0xfffffec0f169bf20 lr: 0xfffffe00519eeb6c fp: 0x0000000000000000 (Full symbolicated stackshot is in the attached panic log.) Context / what was happening - The AmneziaWG split-tunnel was the active default route, with a large allowed-IPs table routed through the utun interface. - Immediately before the panic, an SMB share was mounted — last started kext at 19272083363: com.apple.filesystems.smbfs 6.0.1. In my case this was Google Drive File Stream (it mounts via SMB) syncing through the tunnel, i.e. large TCP segments being pushed through the tunnel. - m_copym_with_hdrs … copy overflow is XNU asserting that the mbuf packet header length (pkthdr.len) exceeds the summed length of the mbuf chain — i.e. a packet whose declared length is inconsistent with its actual buffer chain was handed to / re-injected into the network stack and then copied (TCP output / segmentation path). Why I suspect the AmneziaWG provider - The panic is purely in the network mbuf path, and the only active tunnel was AmneziaWG. - AmneziaWG deliberately modifies packet sizes (junk packets + header obfuscation Jc/Jmin/Jmax/S1/S2/H1–H4). Resizing/rebuilding packets is a classic source of pkthdr.len ↔ mbuf-chain-length mismatch when packets are re-injected via NEPacketTunnelProvider. - Prior art: WireGuard tunnels are known to be able to trigger mbuf panics (e.g. OpenBSD "read-only mbuf passed" reports). The obfuscation layer plausibly widens this window. Frequency First observed occurrence (1 hard panic so far). Same day, preceding signs of stack instability: an AmneziaWG/WireGuard GUI crash on launch and a shutdown_stall. Attached - awg-kernel-panic-2026-06-28.log — full kernel panic log with stackshot. Request Please review how the macOS packet-tunnel provider sets the mbuf packet-header length when rebuilding/re-injecting obfuscated or resized packets — particularly under SMB / large-segment TCP and split-tunnel routing with many routes. If pkthdr.len can diverge from the actual mbuf chain length after junk/obfuscation processing, that would explain the m_copym_with_hdrs overflow. Happy to provide more logs, exact obfuscation parameters, or test a patched build.

bsakaguchi commented

2026-10-13 20:39:12 +00:00

Author

Owner

@Metatau commented on GitHub (Jun 28, 2026):

awg-kernel-panic-2026-06-28.log

@Metatau commented on GitHub (Jun 28, 2026): [awg-kernel-panic-2026-06-28.log](https://github.com/user-attachments/files/29437163/awg-kernel-panic-2026-06-28.log)

No labels

pull-request

No milestone

No project

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/amnezia-client#1266

No description provided.

Rows
Columns