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

abc-mikey opened this Issue Feb 26, 2013 · 8 comments


None yet

6 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 Feb 26, 2013

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.

jnsnow commented Dec 2, 2013

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.

Ruedii commented Mar 24, 2014

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.

I'm seeing this issue trying to run CS: GO

type=AVC msg=audit(1447315069.388:734): avc:  denied  { execheap } for  pid=5299 comm="csgo_linux" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=proce
type=ANOM_ABEND msg=audit(1447315069.458:735): auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=5299 comm="csgo_linux" exe=2F686F6D652F78656E6974682F2E6C6F63616C2F73686172652F537465616D2F73
Ruedii commented Nov 21, 2015

43 and 88 should be moved to this bug, not the other way around.

As of the bug itself, yes, I agree this is a bad idea. It impedes porting this to other platforms.

However, I also think since it's not causing any major bugs, it should be very low priority if it is reopened.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment