Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Steam uses 'execheap' which according to expert ' is really a bad idea' #2028

abc-mikey opened this Issue · 6 comments

5 participants


Ulrich Drepper - the lead contributor and maintainer on GNU C - said this about using execheap:

"The POSIX specification does not permit it, but the Linux implementation of mprotect allows changing the access protection of memory on the heap (e.g., allocated using malloc). This error indicates that heap memory was supposed to be made executable. Doing this is really a bad idea. If anonymous, executable memory is needed it should be allocated using mmap which is the only portable mechanism."

There are a couple of articles about it:

The use of execheap is a Linux wide issue, but the issue was reported by SELinux on Fedora 18. #1471 dismissed it as a Fedora issue incorrectly when it in fact affects Ubnutu and all other Linux distributions equally.


Closing this because it is a known issue and largely a duplicate of #43 and #88.

@MrSchism MrSchism closed this

Sorry but it is not the same issue as #43 or #88.

#43 was closed for being a Fedora only issue and the execheap issue as explained affects all distributions including Ubuntu. #88 is a report for execheap in Webkit, whereas I'm reporting for steam issues unrelated to Webkit.

As brought up by Tinctorius in #88, writeable and executable heap is bad, also see Drepper's article (linked).

Steam is doing this for Half Life 1 and Team Fortress 2 (that I've identified). Also previously it was doing this for big picture mode but I can't reproduce this as big picture mode is not working at all for me.

Here is some output from SELinux for HL1:

type=AVC msg=audit(1361310021.813:3895): avc:  denied  { execheap } for  pid=14938 comm="hl_linux" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1361310021.813:3895): arch=40000003 syscall=125 success=no exit=-13 a0=91c1000 a1=c000 a2=7 a3=ffbd2fcc items=0 ppid=14935 pid=14938 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=5 tty=(none) comm="hl_linux" exe="/home/mikey/.local/share/Steam/SteamApps/common/Half-Life/hl_linux" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

And for TF2:

type=AVC msg=audit(1361920952.323:124): avc:  denied  { execheap } for  pid=5222 comm="hl2_linux" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1361920952.323:124): arch=40000003 syscall=125 success=no exit=-13 a0=92ca000 a1=c000 a2=7 a3=ffa41d1c items=0 ppid=5217 pid=5222 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=2 tty=(none) comm="hl2_linux" exe=2F686F6D652F6D696B65792F2E6C6F63616C2F73686172652F537465616D2F537465616D417070732F6D6F6E636F6D70746532312F5465616D20466F72747265737320322F686C325F6C696E7578 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

It's sad to see how these kinds of Problems get handled by the developers and even more by @MrSchism who really just doesn't even read the bug reports anymore when they are about SELinux.

You treat them as if they were Problem with SELinux even thought they are just Problems shown by SELinux.

To Quote @Tinctorius:
"It is always a Bad Thing to try to make a slab of memory both writable and executable. On Windows, the same thing would be forbidden under Data Execution Prevention (DEP). This should be fixed."

Ans yes. I know. Many of these mistakes are made upstream by some software you use. But as long as you ship it, you need to make QA for it.


I read nearly every issue, to be honest. Those I manage to read are read in their entirety. I may have misread something. Frankly, I'm not sure of everything I read 7 months ago.

I was working under the mindset of a universal solution, as suggested in 88, that execheap shouldn't be required at all.

The WebKit issue, regardless of which OSes experience the issue, is largely the upstream (as you said) and thus not really something that can be handled except by notification upstream. The same solution was proposed in #375 (taking it up-stream).

I can re-open this issue, if you feel it necessary.


It might be nice to keep at least one of these SELinux bugs open as a tracker bug for the upstream problem.

To be frank, if there is a bug in a required library, we either need to work around it or ensure it gets fixed upstream. I don't think it's OK to say "Not our problem," especially when the software crashes as a result.


Webkit is completely open source. It can be handled by fixing the bug and submitting the patch.

Of course, if the maintainers of the upstream version aren't willing to accept said patch, then that is when the issue gets more complicated.

To simply say it's an upstream bug and not fixing it, when the upstream project is open-source, is defeating the whole reason for using open source libraries in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.