Segfault (SEGV_MTESERR) when MTE is enabled

[OneDeuxTriSeiGo]

There is a known issue with the Wireguard Go implementation where Go's GoString implementation causes segfaults due to blowing past tagged memory boundaries. This can be seen in the go upstream in [1] with a proposal to fix this issue long term in [2].

Mullvad has identified a temporary solution [3] that they've deployed until the underlying issues are resolved. As MTE is being deployed in the current latest generation of Android devices and various distributions are beginning to enable this functionality (ex: GrapheneOS), it'd be ideal if a similar hotfix could be applied until the upstream go project adopts a permanent solution.

I've attached evidence of this occurring in the latest released version of ProtonVPN (sourced from F-Droid) in the form of logs from when the app crashes while transitioning from a WiFi connection to an LTE connection[4] and vice versa from an LTE connection to a WiFi connection[5]. The same issue occurs when the cellular connection changes networks.

1. internal/bytealg: valgrind reports invalid reads by C.GoString golang/go#27610
2. proposal: runtime: add support for the Arm’s ArmV8.5-A Memory Tagging Extension (MTE) in Go  golang/go#59090
3. Replace GoString with our own function to fix mte issue mullvad/mullvadvpn-app#6727
4. Error in Proton VPN e4acf70fd0b4.txt
5. Error in Proton VPN dddd8767a97b.txt

[OneDeuxTriSeiGo]

Looking into this some more, I suspect the cause is probably wgTurnOn().

The string is passed into wgTurnOn() here but is then de-allocated in the following lines.

But in between that those strings are further passed into the wireguard device. So there is a likelihood that manually deep copying the settings and socketType strings on the go side of the FFI in wgTurnOn() would prevent any of that tagged memory from leaking in to the go library. From reading through the code in wireguard-android that seems to be the only place where MTE tagged memory segments should be able to leak in.

[OneDeuxTriSeiGo]

Just making a quick note that I updated the logs to instead link to the full MTE crash traces with the specific behavior that triggers it instead of the brief trace available in the logs.