Red Hat Bugzilla – Bug 178262
/usr/lib/libGL.so.1.2 requests an executable stack
Last modified: 2007-11-30 17:11:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.0 (like Gecko)
Description of problem:
# readelf -l /usr/lib/libGL.so.1.2 |grep STACK
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Let me know if it REALLY needs the executable stack and we can change SE Linux
Version-Release number of selected component (if applicable):
Steps to Reproduce:
libGL dlopen()s the individual DRI drivers, which in turn runtime allocate
memory which gets used for runtime code generation, so the memory must be
marked executable in order to function correctly. In previous versions of
Mesa, it just blindly did this with the assumption all stack and heap memory
was executable - thus making it cause exec-shield to be disabled. In XFree86
4.3.0 we had a custom Red Hat patch which made Mesa properly set up the memory
to work nicely with exec-shield, however the patch was dropped due to being
to much effort to forward port to every new release, and the code was rejected
My understanding is that upstream has eventually re-implemented this in
the mesa currently in rawhide, and that it now properly takes care of
ensuring the memory it allocates is flagged PROT_EXEC when need be.
If I'm reading your question right, the answer would be that Mesa does
require dynamically allocated executable memory in order to have functional
Do you need any further info?
Surely if it's only the drivers that allocate such memory then only those
drivers need to be marked as requiring write/execute access? This would mean
that if you use a driver that needs such access then the access is granted,
otherwise it isn't, while the current system grants such access even if no DRI
drivers need it.
I'm probably not the best person to ask, as I'm not really intimately
involved with the Mesa code. Ajax or krh can likely best respond.
Jakub fixed mesa some time back. The first question is why isn't that patch
carried forward? It's a *HUGE* security risk to not do this because all those
crappy desktop apps are linked against libGL. It's also a big step backward
security-wise from previous versions of the distribution.
I do not really know whether the problem was in libGL itself or in the modules
which are loaded. Now that dlopen is used it is in theory indeed possible to
mark only the modules requiring the executable stack as such and not libGL.
I added Jakub to the cc list, he would know.
(In reply to comment #4)
> Jakub fixed mesa some time back. The first question is why isn't that patch
> carried forward?
Jakub submitted it to Mesa upstream at one point, and it was rejected, or
perhaps just ignored, I'm not completely sure. You might want to ask jakub
directly though, as he probably has a better recollection.
Porting patches forward every single OS release, in particular for something
like Mesa which changes drastically every X release, is not viable from
an engineering resource management/allocation perspective, in particular
considering how strained our existing X development resources have been.
It is a general policy of the X Development team, and has been for a very
long time now, that any nontrivial work that is done, must be completed,
submitted upstream by the author, and accepted into upstream CVS before
we will consider including it in our packaging. This is a policy that
was "defacto" for quite a while, but was put in place as an official policy
by our team leader (kem) during development of various team policies.
> It's a *HUGE* security risk to not do this because all those
> crappy desktop apps are linked against libGL.
Of course I'd agree with you on that.
> It's also a big step backward security-wise from previous versions of the
Only from a single version: Red Hat Linux 9.
If memory serves me correctly, that is the only OS release which has ever
shipped with the custom Mesa patch. In retrospect, it was a mistake to
include such a large custom patch at all, until it had been submitted and
accepted by Jakub to the Mesa project.
> I do not really know whether the problem was in libGL itself or in the modules
> which are loaded. Now that dlopen is used it is in theory indeed possible to
> mark only the modules requiring the executable stack as such and not libGL.
We are currently not doing anything special to build Mesa that would cause
libGL to be flagged with an executable stack. I discussed this with ajax
last week, and I believe he indicated that the "linux-dri-x86" build
target will require GNU stacks for some performance reason, but that
the "linux-dri" target doesn't require it.
I think we can all agree that having libGL not require an executable stack,
is beneficial security-wise. I'd also agree that the DRI modules that
require exec-stack should be the only thing that is flagged in that manner.
I don't find it very beneficial in solving this problem to complain about
past decisions that were made, or to wave fingers at people. Let's please
just focus on solving the problems for once and for all, in a manner that
is not going to cause us long term maintenance problems (such as a large
custom patch we have to port forward every OS release).
It shouldn't be difficult to solve this properly for FC5, so I'm adding it
to the FC5Target list.
Additionally, I'd like to point out that the problem that the old
exec-stack patch fixed, was ensuring memory allocated in the DRI
drivers got flagged PROT_EXEC. That is all it did, and that is
already in Mesa that is in rawhide. The problem being surfaced
in _this_ bug report, is an entirely new problem which never existed
in previous OS releases to the best of my knowledge. So kicking sand
over an ancient problem that appears to have been resolved ever
since Mesa 6.4.x hit rawhide, isn't useful.
Is there a workaround for this, so I can use libGL.so?
I guess I am hitting this problem?
amarokapp: error while loading shared libraries: libGL.so.1: cannot enable
executable stack as shared object requires: Permission denied
The upgrade which broke my metacity:
$ sudo grep mesa-libGL /var/log/yum.log
Feb 22 05:48:09 Updated: mesa-libGL.i386 6.4.2-3
Feb 22 05:49:58 Updated: mesa-libGLU.i386 6.4.2-3
Feb 22 05:54:27 Updated: mesa-libGLw.i386 6.4.2-3
The problem with metacity:
metacity: error while loading shared libraries: libGL.so.1: cannot
enable executable stack as shared object requires: Permission denied
# execstack -c /usr/lib/libGL.so.1
The problematic package:
# rpm -q --whatprovides /usr/lib/libGL.so.1
i believe the only dynamic code generation Mesa does these days is done on the
heap and/or in its own writable text section, and not on the stack.
But heap isn't executable either when PT_GNU_STACK program header says PT_R|PT_W.
Unless Mesa explicitly mmaps the memory for dynamically generated code with
PROT_EXEC (or better, yet, creates with PROT_READ|PROT_WRITE and when done
mprotects with PROT_READ|PROT_EXEC), things won't work properly.
*** Bug 182380 has been marked as a duplicate of this bug. ***
(In reply to comment #11)
> But heap isn't executable either when PT_GNU_STACK program header says PT_R|PT_W.
> Unless Mesa explicitly mmaps the memory for dynamically generated code with
> PROT_EXEC (or better, yet, creates with PROT_READ|PROT_WRITE and when done
> mprotects with PROT_READ|PROT_EXEC), things won't work properly.
yes, i believe it does the mprotect method now, even for the -x86 build target.
i'll check of course.
Re comment #5:
> Porting patches forward every single OS release, in particular for something
> like Mesa which changes drastically every X release, is not viable from
> an engineering resource management/allocation perspective,
I do not agree at all. You cannot insist on a pristine package if upstream
isn't willing to pick up critical patches. This is the way things work. Every
package maintainer has such patches they'd like to get rid of.
We have to set priorities and GL disabling all the security features for the
entire desktop is simply no option IMO. Yes, it might mean more resource
requirements on our side (esp the X team) but this is a crucial part of the
security of the system. As Mark's analysis showed, 100% of the security
problems of RHEL4's first year are in the desktop programs, not the server side.
I'm not saying Jakub patch does everything it now has to do and therefore it's
easy to integrate. It's rather unlikely, the original patch mainly dealt with
the stack and perhaps not using malloc for executable memory. The situation now
is more complicated. You must avoid PROT_WRITE^PROT_EXEC mprotect. You cannot
even change PROT_WRITE to PROT_EXEC. It's explained at
That page also has some code explaining how to best solve the problem.
> Porting patches forward every single OS release, in particular for something
> like Mesa which changes drastically every X release, is not viable
I totally agree with Uli. There are in RHEL, as well as FC, a number of
security patches in packages that we carry forward each time due to them not
being acceptable for whatever reason upstream. We are accountable for the risk
our customers face using our distributions, and therefore responsible for doing
everything we can to minimise that risk, even if upstream doesn't agree or it
involves us doing some engineering work at the expense of other fixes or it's
Anyway this issue is no longer about patches being missed, it's a new issue, so
it's something we need to fix in an update and then keep carrying forward if
upstream reject it.
fixed in rawhide, iirc...
Backported the rawhide noexec-stack fixes to FC5 as of mesa-6_4_2-6_FC5_2.
The fix is already in upstream Mesa, and should be included in 6.5.1 and later.
*** Bug 191191 has been marked as a duplicate of this bug. ***
mesa-6.4.2-6.FC5.3 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
From comment #17, I assume this is already fixed in rawhide currently?
The mesa update for FC5 already went out the door. This should be closed
as "RAWHIDE" now if it's fixed I suppose.
(In reply to comment #20)
> The mesa update for FC5 already went out the door. This should be closed
> as "RAWHIDE" now if it's fixed I suppose.
ACK, fixed in rawhide.