[GH-ISSUE #2637] macOS: AmneziaVPN-service crashes with SIGSEGV on connection attempt, leaving network unreachable #1195

New issue

Open

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

bsakaguchi commented

2026-10-13 20:36:36 +00:00

Owner

Originally created by @Wooden210 on GitHub (May 21, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2637

Environment

macOS Sequoia 15.7.7 (24G720)
AmneziaVPN 4.8.15.4 (2edd7de)
Hardware: MacBook Pro 17,1 (x86_64 via Rosetta 2)
Protocol: AmneziaWG (amnezia-awg2 container)

Behavior

When pressing "Connect", AmneziaVPN-service crashes with SIGSEGV, leaving the routing table broken and the entire network unreachable until reboot.

Crash happens multiple times per session (confirmed in DiagnosticReports).

Crash info

Exception: EXC_BAD_ACCESS (SIGSEGV) — KERN_INVALID_ADDRESS at 0x0000000000000008

Faulting stack trace:

DaemonLocalServerConnection::write(QJsonObject const&)
DaemonLocalServerConnection::disconnected()         ← null ptr dereference here
DaemonLocalServerConnection::parseCommand(QByteArray const&)
DaemonLocalServerConnection::readData()
QAbstractSocketPrivate::canReadNotification()
QCoreApplication::sendEvent()
QEventDispatcherUNIX::processEvents()
QEventLoop::exec()
QCoreApplication::exec()
main

Root cause

Race condition: when a new connection attempt is initiated while a previous one is still deactivating, disconnected() is called on a DaemonLocalServerConnection object that has already been freed/nulled, causing a null pointer dereference at offset +8.

Visible in app log:

[17:42:50] LocalSocketController: Deactivating
[17:42:50] VpnProtocol::setConnectionState "Отключено"
[17:42:50] LocalSocketController: Deactivating    ← second call while first still in progress
[17:42:50] VpnProtocol::setConnectionState "Отключено"

Network impact

After crash, routing table contains stale entries:

0/1      utun4   ← all traffic routed to dead VPN interface
128.0/1  utun4

This blocks all internet traffic. KeepAlive=true restarts the daemon, but stale routes remain, requiring full reboot to recover.

Steps to reproduce

Have an AmneziaWG connection configured
Click "Connect"
While connecting, click "Connect" again or let it fail and retry quickly

Expected behavior

Service should not crash; on disconnect/retry it should safely handle already-freed connection objects. On service crash, routes should be cleaned up (e.g. via launchd cleanup handler).

Originally created by @Wooden210 on GitHub (May 21, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2637 ## Environment - macOS Sequoia 15.7.7 (24G720) - AmneziaVPN 4.8.15.4 (2edd7de) - Hardware: MacBook Pro 17,1 (x86_64 via Rosetta 2) - Protocol: AmneziaWG (amnezia-awg2 container) ## Behavior When pressing "Connect", `AmneziaVPN-service` crashes with SIGSEGV, leaving the routing table broken and the entire network unreachable until reboot. Crash happens multiple times per session (confirmed in DiagnosticReports). ## Crash info **Exception:** EXC_BAD_ACCESS (SIGSEGV) — KERN_INVALID_ADDRESS at 0x0000000000000008 **Faulting stack trace:** ``` DaemonLocalServerConnection::write(QJsonObject const&) DaemonLocalServerConnection::disconnected() ← null ptr dereference here DaemonLocalServerConnection::parseCommand(QByteArray const&) DaemonLocalServerConnection::readData() QAbstractSocketPrivate::canReadNotification() QCoreApplication::sendEvent() QEventDispatcherUNIX::processEvents() QEventLoop::exec() QCoreApplication::exec() main ``` ## Root cause Race condition: when a new connection attempt is initiated while a previous one is still deactivating, `disconnected()` is called on a `DaemonLocalServerConnection` object that has already been freed/nulled, causing a null pointer dereference at offset +8. Visible in app log: ``` [17:42:50] LocalSocketController: Deactivating [17:42:50] VpnProtocol::setConnectionState "Отключено" [17:42:50] LocalSocketController: Deactivating ← second call while first still in progress [17:42:50] VpnProtocol::setConnectionState "Отключено" ``` ## Network impact After crash, routing table contains stale entries: ``` 0/1 utun4 ← all traffic routed to dead VPN interface 128.0/1 utun4 ``` This blocks all internet traffic. `KeepAlive=true` restarts the daemon, but stale routes remain, requiring full reboot to recover. ## Steps to reproduce 1. Have an AmneziaWG connection configured 2. Click "Connect" 3. While connecting, click "Connect" again or let it fail and retry quickly ## Expected behavior Service should not crash; on disconnect/retry it should safely handle already-freed connection objects. On service crash, routes should be cleaned up (e.g. via launchd cleanup handler).

bsakaguchi commented

2026-10-13 20:36:37 +00:00

Author

Owner

@nedlis94-prog commented on GitHub (May 22, 2026):

+1, confirming the same crash on macOS 26.4.1 (build 25E253) on MacBook Air M4 (Apple Silicon, arm64).

Setup:

Hardware: MacBook Air M4 (Mac16,12)
OS: macOS 26.4.1 (25E253)
Amnezia client: tested on 4.8.12 and 4.8.15.4 (both crash, both are x86_64 running under Rosetta 2)
Protocol: AmneziaWG Legacy

Symptoms:

GUI shows "Connecting…" indefinitely on AmneziaWG Legacy.
utun4 interface comes up with MTU 1376 but never gets an IPv4 address — handshake doesn't complete.
On Xray protocol the GUI reports "Connected" but no traffic flows (tun2socks creates the local interface, but AmneziaVPN-service
can't establish outbound TCP — lsof shows dozens of sockets stuck in SYN_SENT to the server endpoint).
The same servers/configs work perfectly on iPhone (iOS Amnezia) and Windows (Amnezia 4.8.12) on the same Wi-Fi.
Worked stably for ~6 months until May 20, 2026. Crashed for the first time at 12:03 MSK that day. Has been broken since.

Crash signatures (attached .ips files):

AmneziaVPN (4.8.12), 2026-05-20 12:03:21:

Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x000000000000006e
Faulting thread: QThread, frames include XrayProtocol::stop(), VpnConnection::disconnectFromVpn(),
IpcProcessTun2SocksReplica::setConnectionState(int)
translated: true (Rosetta 2)

AmneziaVPN-service, 2026-05-22 13:59:53:

Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0000000000000008
Faulting thread (main): DaemonLocalServerConnection::readData() → _sigtramp
Go-runtime frames in other threads (runtime.findRunnable, runtime.schedule, etc.)
translated: true (Rosetta 2)

What I tried (didn't help):

Full uninstall + clean reinstall (5x), including manual removal of
~/Library/Preferences/{com.yourcompany,org.amneziavpn}.AmneziaVPN.plist, ~/Library/Caches/AmneziaVPN.ORG,
/Library/LaunchDaemons/AmneziaVPN.plist, /Library/Application Support/AmneziaVPN.
Tried both 4.8.12 (.dmg) and 4.8.15.4 (.pkg) — same crash signatures.
Tested with mobile hotspot — same result, so it's not the local network or the ISP.
System is clean: no config profiles (profiles show -type configuration empty), pfctl disabled, no third-party VPN clients
installed.

Workaround:
Switched to the native AmneziaWG app from the Mac App Store (id6478942365 by Privacy Technologies OU) — works fine, no crashes. This
confirms the issue is specific to the x86_64 amnezia-client build under Rosetta 2, not to the AmneziaWG protocol or the server.

Please consider shipping a native arm64 build of amnezia-client — this would resolve the issue at the root for all M-series Mac users.

@nedlis94-prog commented on GitHub (May 22, 2026): +1, confirming the same crash on macOS 26.4.1 (build 25E253) on MacBook Air M4 (Apple Silicon, arm64). **Setup:** - Hardware: MacBook Air M4 (Mac16,12) - OS: macOS 26.4.1 (25E253) - Amnezia client: tested on 4.8.12 and 4.8.15.4 (both crash, both are x86_64 running under Rosetta 2) - Protocol: AmneziaWG Legacy **Symptoms:** - GUI shows "Connecting…" indefinitely on AmneziaWG Legacy. - `utun4` interface comes up with MTU 1376 but never gets an IPv4 address — handshake doesn't complete. - On Xray protocol the GUI reports "Connected" but no traffic flows (tun2socks creates the local interface, but `AmneziaVPN-service` can't establish outbound TCP — `lsof` shows dozens of sockets stuck in `SYN_SENT` to the server endpoint). - The same servers/configs work perfectly on iPhone (iOS Amnezia) and Windows (Amnezia 4.8.12) on the same Wi-Fi. - Worked stably for ~6 months until May 20, 2026. Crashed for the first time at 12:03 MSK that day. Has been broken since. **Crash signatures (attached .ips files):** `AmneziaVPN` (4.8.12), 2026-05-20 12:03:21: - Exception: `EXC_BAD_ACCESS (SIGSEGV)`, `KERN_INVALID_ADDRESS at 0x000000000000006e` - Faulting thread: `QThread`, frames include `XrayProtocol::stop()`, `VpnConnection::disconnectFromVpn()`, `IpcProcessTun2SocksReplica::setConnectionState(int)` - `translated: true` (Rosetta 2) `AmneziaVPN-service`, 2026-05-22 13:59:53: - Exception: `EXC_BAD_ACCESS (SIGSEGV)`, `KERN_INVALID_ADDRESS at 0x0000000000000008` - Faulting thread (main): `DaemonLocalServerConnection::readData()` → `_sigtramp` - Go-runtime frames in other threads (`runtime.findRunnable`, `runtime.schedule`, etc.) - `translated: true` (Rosetta 2) **What I tried (didn't help):** - Full uninstall + clean reinstall (5x), including manual removal of `~/Library/Preferences/{com.yourcompany,org.amneziavpn}.AmneziaVPN.plist`, `~/Library/Caches/AmneziaVPN.ORG`, `/Library/LaunchDaemons/AmneziaVPN.plist`, `/Library/Application Support/AmneziaVPN`. - Tried both 4.8.12 (.dmg) and 4.8.15.4 (.pkg) — same crash signatures. - Tested with mobile hotspot — same result, so it's not the local network or the ISP. - System is clean: no config profiles (`profiles show -type configuration` empty), `pfctl` disabled, no third-party VPN clients installed. **Workaround:** Switched to the native AmneziaWG app from the Mac App Store (id6478942365 by Privacy Technologies OU) — works fine, no crashes. This confirms the issue is specific to the x86_64 `amnezia-client` build under Rosetta 2, not to the AmneziaWG protocol or the server. Please consider shipping a native arm64 build of `amnezia-client` — this would resolve the issue at the root for all M-series Mac users.

bsakaguchi referenced this issue

2026-10-13 21:20:20 +00:00

[PR #1195] [MERGED] bugfix/api auth data saving #2268