Mullvad VPN setup guide

Bimmy · May 31, 2026, 6:33pm

Update / Addition to my above message:

Short Version:

On fedora-43 (gnome) I got the Mullvad App fully working, including GUI frontend.
On fedora-44-gnome, I got the CLI version working, but GUI frontend fails when hardened_malloc is configured.

Longer Version:
I followed the guide with recent templates plus the following modifications in script fedora-gnome.sh:

Changed handling of package openh264:
No removal but replacement by noopenh264. (Reasons and further details in outsourced thread: https://forum.qubes-os.org/t/fedora-43-gnome-template-sudo-dnf-remove-openh264-destroys-template/40789/13).
Changed secureblue’s COPR repository:
secureblue/hardened_malloc had become outdated; replaced by secureblue/packages.

With this, I could make Mullvad VPN fully working on Fedora 43 (based on template version 0:4.3.0-202601041226 ).
On Fedora 44, based on the most recent template (as of now: version 0:4.3.0-202605021558 from repository qubes-templates-itl-testing ), I only could get the CLI version running; the GUI frontend fails with memory allocator errors.

Symptoms:

Attempting to open Mullvad VPN from the respective qube’s applications menu has no apparent effect. No window opens.
When called from command line via:
/opt/Mullvad\ VPN/mullvad-gui → On Fedora 44 this immediately aborts with the following error message:

fatal allocator error: invalid uninitialized allocator usage
Aborted                    (core dumped) /opt/Mullvad\ VPN/mullvad-gui

Own investigation:

I did some debugging. I presume the exact error message originates from hardened_malloc’s function enforce_init.
- See source code for further details: https://github.com/GrapheneOS/hardened_malloc/blob/14/h_malloc.c#L1209
I could successfully reach a Mullvad GUI window, if I went with standard allocator by NOT adding libhardened_malloc.so in etc/ld.so.preload, which confirms some incompatibility between Mullvad VPN and hardened_malloc .
I’d prefer to keep hardened_malloc and rather fall back to Mullvad CLI. Nonetheless, keeping the standard allocator and not using hardened_malloc might serve as a reasonable workaround for other users. This is in line with the support channel of secureblue distribution, where they apparently face the same sort of problem – although they have a more beautiful workaround by selectively changing the allocator only for the mullvad GUI frontend via an additional ujust script.
I found it interesting that the mullvad binary details were the exact same on both fedora 43 and fedora 44:

[user@fedora ~]$ file /opt/Mullvad\ VPN/mullvad-gui
/opt/Mullvad VPN/mullvad-gui: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a8d981bf4ad25c52e588ebdf49c48cc1c05be07b, stripped

What definitely differs between fedora 43 and 44 versions is (libc-related) shared object dependencies.
(libc) related dependency details for f43:

[user@fedora ~]$ ldd /opt/Mullvad\ VPN/mullvad-gui | grep libc
	libhardened_malloc.so => /lib64/glibc-hwcaps/x86-64-v3/libhardened_malloc.so (0x00007447a8e48000)
	libcups.so.2 => /lib64/libcups.so.2 (0x000074479c41e000)
	libcairo.so.2 => /lib64/libcairo.so.2 (0x000074479c2e0000)
	libc.so.6 => /lib64/libc.so.6 (0x000074479b49e000)
	libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x000074479a7c2000)
	libcloudproviders.so.0 => /lib64/libcloudproviders.so.0 (0x000074479a65a000)
	libcap.so.2 => /lib64/libcap.so.2 (0x000074479a542000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000074479a41d000)
	libcrypto.so.3 => /lib64/libcrypto.so.3 (0x0000744799e00000)

[user@fedora ~]$ dnf list --installed | grep -E "(glibc|gcc)"
annobin-plugin-gcc.x86_64                            12.99-1.fc43                     fedora
gcc.x86_64                                           15.2.1-7.fc43                    updates
gcc-c++.x86_64                                       15.2.1-7.fc43                    updates
gcc-plugin-annobin.x86_64                            15.2.1-7.fc43                    updates
glibc.i686                                           2.42-12.fc43                     updates
glibc.x86_64                                         2.42-12.fc43                     updates
glibc-common.x86_64                                  2.42-12.fc43                     updates
glibc-devel.x86_64                                   2.42-12.fc43                     updates
glibc-gconv-extra.i686                               2.42-12.fc43                     updates
glibc-gconv-extra.x86_64                             2.42-12.fc43                     updates
glibc-langpack-en.x86_64                             2.42-12.fc43                     updates
glibc-minimal-langpack.x86_64                        2.42-12.fc43                     updates
libgcc.i686                                          15.2.1-7.fc43                    updates
libgcc.x86_64                                        15.2.1-7.fc43                    updates

ditto for f44:

[user@fedora ~]$ ldd /opt/Mullvad\ VPN/mullvad-gui | grep libc
	libhardened_malloc.so => /lib64/glibc-hwcaps/x86-64-v3/libhardened_malloc.so (0x00007bf16ec89000)
	libcups.so.2 => /lib64/libcups.so.2 (0x00007bf162236000)
	libcairo.so.2 => /lib64/libcairo.so.2 (0x00007bf1620ec000)
	libc.so.6 => /lib64/libc.so.6 (0x00007bf16120c000)
	libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x00007bf160b0d000)
	libcloudproviders.so.0 => /lib64/libcloudproviders.so.0 (0x00007bf160310000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007bf1600da000)
	libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007bf15fa00000)

[user@fedora ~]$ dnf list --installed | grep -E "(glibc|gcc)"
annobin-plugin-gcc.x86_64                            13.14-1.fc44                     updates
gcc.x86_64                                           16.1.1-2.fc44                    updates
gcc-c++.x86_64                                       16.1.1-2.fc44                    updates
gcc-plugin-annobin.x86_64                            16.1.1-2.fc44                    updates
glibc.i686                                           2.43-5.fc44                      updates
glibc.x86_64                                         2.43-5.fc44                      updates
glibc-common.x86_64                                  2.43-5.fc44                      updates
glibc-devel.x86_64                                   2.43-5.fc44                      updates
glibc-gconv-extra.i686                               2.43-5.fc44                      updates
glibc-gconv-extra.x86_64                             2.43-5.fc44                      updates
glibc-langpack-en.x86_64                             2.43-5.fc44                      updates
glibc-minimal-langpack.x86_64                        2.43-5.fc44                      updates
libgcc.i686                                          16.1.1-2.fc44                    updates
libgcc.x86_64                                        16.1.1-2.fc44                    updates

I’ve got some gdb and strace output. I assume posting everything will be too much and probably out-of-scope, but I can provide it if there is interest. Preview / "Spoiler:
- Apart from concrete memory addresses, the strace looks pretty similiar EXCECT that
- the f43-trace has a call to libcap at some point in time
- the f44-trace has an additional pair of calls to mmap and prctl, respectively, somewhere in close vicinity before the abort.
I haven’t found the exact rootcause. If someone can and wants to provide additional input, I’ll be grateful.
I might or might not be relevant, that there are other sources reporting about conflicts between certain apps and hardened_malloc, particularly when an application uses additional, custom allocators and/or the electron framework is involved. (To my knowledge, Mullvad VPN app indeed uses electron.) Example further reading:
- Reports about a chrome issue – note: Chrome uses another, custom allocator, Partition Alloc – which involves chrome crashing with same error message: https://issues.chromium.org/issues/486362478
- A recent remark in a different context but regarding reasons for compatibility issues from hardened_malloc-Development team in general: https://discuss.grapheneos.org/d/32249-hardened-malloc-version-14-released/2.

Again, Tommy, thank you very much for the guide. Even with described issues at f44, it allows me to use mullvad (CLI) in a more hardened setup, and I found your explanations and scripts very inspiring and a good opportunity to learn. I’ll probably use it as long as it works. And should you ever post updates specifically for F44 or higher, I’ll be even more happy. Even if this is the last version of the guide - and hopefully mullvad does a bit more to simplify the integration and improve the compatibility with Qubes and hardened template setups on their own - I find it a priviledge to read users like you sharing their experience and tools. A great help for the community.