Mullvad VPN silently randomly crashes both in foreground and in background without any notifications after working normally for some time, and there is no crash in app's logs on Pixel 8. It works perfectly fine on Pixel 7 though. In scenarios when need to I use 4-5 or more apps in a short period of time, Mullvad VPN crashes more often.

On both Pixels

  • hardened memory allocator enabled,
  • native code debugging blocked,
  • DLC via memory restricted,
  • DLC via storage restricted, and
  • on Pixel 8 memory tagging is enabled (the only difference).

Their support after not finding any crashes in app's logs (both internal and GrapheneOS') suggest me to disable hardened memory allocator, but I don't understand why, if it isn't needed on Pixel 7.

Here are my questions:

  • Why there is a difference in app's behavior on Pixel 8 and Pixel 7?
  • Do I really need to choose between (1) restarting Mullvad VPN multiple times a day and (2) disabling hardened memory allocator (I did not tested it long enough to tell if it helps)?
  • Are there any differences in hardened malloc on different devices that can cause this?
  • Can it be a hardware problem (I bought used Pixel 8 and cannot be 100% sure that it's hardware is untouched, Auditor's output seems OK)?

    Calculator Do I really need to choose between (1) restarting Mullvad VPN multiple times a day and (2) disabling hardened memory allocator (I did not tested it long enough to tell if it helps)?

    At some point, for security and privacy companies, the question should maybe become "Why aren't you testing your code on the most secure Android variant, which can uncover bugs that affect all Android platforms, including vulnerabilities?".

    If the hardware budget at a security/privacy company can't cover one Pixel 8 or newer... if the testing plan can't handle one more platform... how much testing is happening? Just how safe is user data actually?

        The biggest question here is why you'd use this over Wireguard or WG Tunnel.

          wuseman Because plain Wireguard connection is slowed down and sometimes even blocked completely in my country. App has an obfuscation through Shadowsocks which helps a lot, also it allows me to change exit country, while Wireguard is limited in that: Mullvad VPN allows maximum 5 devices (Wireguard configurations, OpenVPN configurations and apps' logged in sessions combined)

              Just joining in to confirm that Mullvad is randomly crashing on my Pixel 8 Pro. It can be very reliably triggered by opening the app after a while and tapping the server button in order to change servers. It started to happen alongside enabling memory tagging, so that being the cause would be my best guess as well.

              wuseman The biggest question here is why you'd use this over Wireguard or WG Tunnel.

              This is not relevant to OP's questions and rather patronizing. People have all sorts of reasons to do what they do, like ease of setup and convenience or app-specific features.

                Calculator Their support after not finding any crashes in app's logs (both internal and GrapheneOS') suggest me to disable hardened memory allocator, but I don't understand why, if it isn't needed on Pixel 7.

                I think the (admittedly quite long) discussion in the following Github issue will shed some light on your question: https://github.com/mullvad/mullvadvpn-app/issues/6349

                In short, Mullvad fixed a memory safety issue but there are apparently still issues that are uncovered by memory tagging usage with hardened_malloc on GrapheneOS. Seemingly more bugs are uncovered compared to running the app with memory tagging using Android's stock allocator (Scudo). When you disable hardened_malloc for an app while keeping memory tagging enabled for that app, the app will be running with the memory tagging implementation that is available on stock PixelOS (source).

                Mullvad used to have a memory corruption bug upon each tunnel connect, which was revealed by MTE usage and Scudo (running the app with MTE enabled and hardened_malloc disabled used to crash the app on GrapheneOS), but Mullvad appears to have fixed that with a commit a few versions ago.

                Calculator Can it be a hardware problem (I bought used Pixel 8 and cannot be 100% sure that it's hardware is untouched, Auditor's output seems OK)?

                It is not a hardware problem. Memory tagging is working as intended.

                Calculator Are there any differences in hardened malloc on different devices that can cause this?

                There are some technical details on this in the Github issue I linked above – specifically in this comment by a GrapheneOS developer: https://github.com/mullvad/mullvadvpn-app/issues/6349#issuecomment-2381665133

                de0u At some point, for security and privacy companies, the question should maybe become "Why aren't you testing your code on the most secure Android variant, which can uncover bugs that affect all Android platforms, including vulnerabilities?".

                It's a very good point, and I think more companies should follow Mullvad's example by running their apps on GrapheneOS with memory tagging.

                          fid02 Thank you for sharing this. I guess all we can do now is to wait for fix from Mullvad.

                            A user is reporting that there are no issues while running version 2024.9-beta. Is anyone able to confirm that running that version with Hardened malloc and memory tagging works fine?

                              fid02 Well, it doesn't crash but connection becomes very poor after some time. Example: pages do not load or load too slow, videos are buffering more time than they last. Not really sure it's Mullvad VPN's problem, maybe it's just my WiFi. However, it seems to be better just after full restart of the app (including force stopping)

                                  Calculator Try changing servers. I haven't noticed any difference in connection quality compared to other versions.

                                      fid02 It doesn't help. I tested it for a quite short time and my WiFi speed is unstable (no chance of improving that), so I need more time to be more sure what causes connection quality degradation.

                                        Calculator also it allows me to change exit country, while Wireguard is limited in that: Mullvad VPN allows maximum 5 devices (Wireguard configurations, OpenVPN configurations and apps' logged in sessions combined)

                                        No, actually. You can generate configs for multiple servers for the same private key (device), so you could have a config for dozens of different servers while only having one device registered.

                                        It doesn't help your current case, because of the blocking problem in your country, but for someone else who might be unsure about using plain Wireguard, there is a solution for this.

                                            It dumbfounds me how every larger company building android apps is not using a grapheneos pixel for alpha testing. Can't wait to see the fun start with A16 when mem tagging is on by default. Maybe we will see mem hardening as well. Its ridiculous the amount of super popular apps many security related that have these mem coding errors. At least some of them have to be expiotable at least on other phones and stock pixels.

                                            Ammako Can you explain how to do that? I have reserve Wireguard configs in case something happens with connection through app (hoping Wireguard wouldn't be completely blocked at that time)

                                              fid02 Everything seems to work how it should with this beta version. Connection drops I reported earlier were caused by WiFi just being bad, I guess.

                                                8 days later

                                                fid02

                                                I didn't test the beta however the latest stable build appears to be working just fine with both enabled.

                                                Not sure if my feedback is worth anything now of course but I thought I'd say it just in case!