What differences in security and memory‑safety testing were found between Mullvad’s app and the official WireGuard app on GrapheneOS?
Executive summary
GrapheneOS’s public guidance says Mullvad’s Android client has been explicitly tested under GrapheneOS’s hardware memory tagging configuration, whereas the official WireGuard app triggers invalid-memory-access detections when memory tagging is enabled on GrapheneOS [1]. Beyond that core finding, community threads note functional differences (for example, Mullvad’s app lacks built-in multi‑hop while WireGuard can import Mullvad multi‑hop configs), but GrapheneOS’s statement is the only direct, security‑testing claim in the available reporting [2] [3].
1. The concrete memory‑safety finding reported by GrapheneOS
GrapheneOS’s FAQ reports a direct, test‑based distinction: Mullvad’s Android app “is tested on GrapheneOS with hardware memory tagging,” while the official WireGuard app exhibits “invalid memory accesses detected by memory tagging if it’s enabled” [1]. That statement is presented as a factual outcome of GrapheneOS’s testing regime rather than a theoretical critique of the WireGuard protocol or its design, and it is the primary source for the security difference between the two binaries on that OS [1].
2. What “hardware memory tagging” detection implies—GrapheneOS’s perspective
Hardware memory tagging (MTE/ASAN‑like facilities in modern Arm chips) is used by GrapheneOS as an active detection mechanism to expose latent memory safety bugs; GrapheneOS’s FAQ frames its recommendation around apps that survive testing with tagging enabled [1]. By flagging invalid memory accesses in the official WireGuard app, GrapheneOS is not necessarily asserting exploitable remote vulnerabilities but is reporting that the WireGuard binary contains code paths that violate strict memory‑safety checks under their hardened runtime configuration [1].
3. Functional and UX differences raised by users that are distinct from memory safety
Discussion threads on the GrapheneOS forums highlight other practical distinctions between using the official WireGuard client and Mullvad’s app—most notably that Mullvad’s Android client historically didn’t include Mullvad’s multi‑hop feature, while users can instead create multi‑hop WireGuard configs and import them into the WireGuard app [2] [3]. Those operational differences matter for privacy/feature choices but are separate from the memory‑safety testing GrapheneOS describes [2] [3].
4. Alternative viewpoints and the limits of the public record
The sources provided do not include a detailed technical audit, stack traces, or CVE‑style reports backing GrapheneOS’s summary; the FAQ is an authoritative statement from GrapheneOS but stops short of publishing the raw memory‑tagging logs or confirming exploitability [1]. Community threads reflect user practice and feature workarounds but are not replacement for an independent code audit of either app; absent such artifacts, it is accurate to report GrapheneOS’s test result while acknowledging that additional technical proof or vendor responses are not present in the provided reporting [2] [3].
5. Hidden incentives and agendas to consider when weighing these claims
GrapheneOS has a security posture that emphasizes hardware‑level mitigations and careful app recommendations; its public guidance favors apps that pass its specific hardening tests, which can create pressure on app vendors to fix memory‑safety issues to regain explicit endorsement [1]. On the vendor side, Mullvad benefits from being portrayed as GrapheneOS‑compatible, while WireGuard’s upstream project and distributions might argue that reported invalid accesses are benign in practice or platform‑specific—none of those vendor rebuttals are visible in the sources provided, so the FAQ stands as the primary claim [1].
6. Practical takeaways for a security‑focused user on GrapheneOS
For users who prioritize GrapheneOS’s hardened runtime checks, the FAQ’s simple guidance is decisive: Mullvad’s app has been tested and passed with memory tagging enabled, while the official WireGuard app triggers memory‑tagging detections according to GrapheneOS’s tests [1]. If multi‑hop or specific WireGuard configurations are required, community discussion documents workarounds—creating Mullvad multi‑hop configs and importing them into the WireGuard app remains a path, but it does not negate the memory‑safety testing result reported by GrapheneOS [2] [3].