Bug: Hardened Malloc Ignored by Flatpaks

But even if it doesn’t make sense for Chromium, would be useful to know generally for other applications from flatpak.

Hi folks, has anyone brainstormed this further or gotten flatpak working with hardened malloc in any capacity? I’m aiming to include this functionality in my security-focused image (github - /secureblue/secureblue) based on immutable fedora, and if someone’s already figured out how to do this I want to avoid reinventing the wheel. We have an ongoing thread there as well but I can’t link it here so I figured I’d ask.

No progress. And none should be expected. If there was progress, it would be posted here.

Hello :slight_smile:

While experimenting on a Fedora Silverblue VM I’ve found:

You can override the /usr in the runtime with the hosts /usr with the following flag:


And then successfully preload the library:

flatpak run --usr-path=/usr --env=LD_PRELOAD=/usr/lib64/libhardened_malloc.so org.gnome.Calculator

Over at secureblue we have since found a way to get this working, thanks to @34n0

Instead of using usr path, we have a short script that copies libhardened_malloc.so into ~/.local, and then override permissions for all flatpaks to grant them read only access specifically to that file only. They then use it when passed in the LD_PRELOAD environment variable, confirmed for several apps in /proc/$PID/maps.

A handful of apps still ignore it, notably steam, vscodium, and discord. But most apps I’ve tested so far don’t ignore it and do load it.


Following here:

Interesting! Thanks for sharing!

(Upgraded your account just now. You can post links normally now.)


I think so yes. If the runtime’s /usr contains libraries which do not exist on the host. This method is flawed in other ways too… At least it proved a flatpak process can preload the library. :smile:

Thanks, here’s the PR to add this functionality:

If folks here have any additional input on the approach, it would be greatly appreciated.

1 Like

Left some comments there. :slight_smile:

Thanks, I’ve come up with a new solution I posted there. In short, we can directly reference


The only downside is that this requires


Which gives all flatpaks readonly access to all of /usr.

So now the question is whether this is a desirable tradeoff in favor of letting flatpaks use hardened_malloc.

1 Like

Before applying more complex workarounds, hacks, it’s best to contact upstream (flatpak) first. They either might have a solution or then there’s at least a ticket which explains the issue which might get fixed one day. Then no complex workarounds, hacks are needed.

Piling these up without proper documentation (which is done by reporting these upstream) makes a project difficult to maintain in the future.

There’s already an upstream ticket for this here: [Bug]: Can't access `/usr` with permission · Issue #5575 · flatpak/flatpak · GitHub

I’ll bump it with our concerns, but as of now it’s closed as Not Planned.

1 Like

Bumped: [Bug]: Can't access `/usr` with permission · Issue #5575 · flatpak/flatpak · GitHub

1 Like

Excellent… Thank you for opening the feature request!