Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 598700 - =www-client/firefox-49.0 segfaults with >=media-libs/mesa-13.0.0_rc1 on >=4.4.8-hardened-r1
Summary: =www-client/firefox-49.0 segfaults with >=media-libs/mesa-13.0.0_rc1 on >=4.4...
Status: RESOLVED DUPLICATE of bug 598593
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Team
Depends on:
Reported: 2016-11-01 19:48 UTC by miro.rovis
Modified: 2016-11-14 06:04 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

firefox-49_161101_1126_syslog (firefox-49_161101_1126_syslog,2.14 KB, text/plain)
2016-11-01 19:52 UTC, miro.rovis
firefox-49_161101_1140_syslog_dri_allowed (firefox-49_161101_1140_syslog_dri_allowed,1.45 KB, text/plain)
2016-11-01 19:53 UTC, miro.rovis
irefox-49_161101_1738_syslog_-PAX_MPROTECT (firefox-49_161101_1738_syslog_-PAX_MPROTECT,1.31 KB, text/plain)
2016-11-01 19:53 UTC, miro.rovis
firefox-49_161101_1850_syslog_-PAX_RANDMAP (firefox-49_161101_1850_syslog_-PAX_RANDMAP,1.44 KB, text/plain)
2016-11-01 19:54 UTC, miro.rovis

Note You need to log in before you can comment on or make changes to this bug.
Description miro.rovis 2016-11-01 19:48:36 UTC
title: =www-client/firefox-49.0 segfaults with >=media-libs/mesa-13.0.0_rc1 on

Before I describe the problem, I want to say that I don't have this issue with
# equery l firefox
 * Searching for firefox ...
[IP-] [  ] www-client/firefox-45.4.0:0

Starting Firefox from command line, at first looked consistently like this:
$ firefox
1477995790997	addons.xpi	WARN	Add-on is not correctly signed.
MESA-LOADER: failed to retrieve device information
ATTENTION: default value of option force_s3tc_enable overridden by environment.
unknown chip id 0x6759, can't guess.
libGL error: failed to create dri screen
libGL error: failed to load driver: radeon
ATTENTION: default value of option force_s3tc_enable overridden by environment.

And here, the first batch of syslog goes.
Pls. note there will be another which will correspond to my adding of:
subject /usr/lib64/firefox
in my /etc/grsec/policy

(It is good to recall here that I haven't needed to mess with the mprotect or
randmap enabling for Firefox in Gentoo with my grsecurity-hardened-sources
kernel never or almost never, since one or two years...)

With this first batch of syslog messages, MPROTECT was enabled (as per: by
default, not a line in policy under the subject) for /usr/lib64/firefox.


then I changed:

	/dev/dri/card0	rw


	/dev/dri		rw

in the subject /usr/lib64/firefox

and the syslog is that much shorter:


But still no work. Now goes the second batch of no stdout when starting
firefox, only frozen start of, nothing running, and also hard to kill.

Remember that this batch is after I disabled:


for /usr/lib64/firefox

So, no stdout, but this in the syslog:


And I think I also disabled:


for firefox, to get this:



Before allowing  rw to /dev/dri the syslog PAX terminates task before.

But after allowing  rw to /dev/dri of the syslog there is the apparent
culprit there pretty consistently showing up:

$ grep libGL firefox*syslog*
firefox-49_161101_1140_syslog_dri_allowed:Nov  1 11:39:46 g5n kernel:
[94310.848881] firefox[20279]: segfault at c ip 00000393a01460a0 sp
000003a0d5484300 error 4 in[393a00ef000+7b000]
firefox-49_161101_1738_syslog_-PAX_MPROTECT:Nov  1 17:38:19 g5n kernel:
[115824.530232] firefox[5205]: segfault at c ip 000003a2bb1460a0 sp
000003b4813ea940 error 4 in[3a2bb0ef000+7b000]
firefox-49_161101_1850_syslog_-PAX_RANDMAP:Nov  1 18:50:18 g5n kernel: [
3100.950678] firefox[4598]: segfault at c ip 00000380c25460a0 sp
000003a3ec617c20 error 4 in[380c24ef000+7b000]

And also I can tell:
# equery b /usr/lib64/ 
 * Searching for /usr/lib64/ ... 
media-libs/mesa-13.0.0_rc2 (/usr/lib64/
# equery k mesa
* Checking media-libs/mesa-13.0.0_rc2 ...
   123 out of 123 files passed

I also think similar but milder issue I had with =media-libs/mesa-13.0.0_rc1.

Let me tell that I tried this with kernels:


and I didn't notice any difference.

However that's the much that I can tell. Ah, I almost forgot to also note

# equery k firefox
* Checking www-client/firefox-49.0 ...
   79 out of 79 files passed

my Firefox is as Releng signed it (or else something very sinister is at

And I can tell that I install with emerge-webrsync with Releng signed portage
snapshots *exclusively* in my Air-Gapped master that never sees any internet,
from its own Air-Gapped mirror that never directly sees any internet, but gets
its updates after Clamav run on the new arrivals from the not-constantly
online mirror (but a mirror that opens to the internet for updates), and
careful hashing before and after optical media only transfer to Air-Gapped

Also, my system may still have somehow (and I really wonder how!) been victim
of intrusion, since the likely use-after-free condition seems to exist, as per

>=sys-kernel/hardened-sources-4.7.6: Kernel panic when starting KVM guests

And that really is all that I can tell... I will next post the
files/attachments that I named above (at the HERE keywords).

Can I forgo posting the emerge --info since not much at all has changed since:

The emerge--info.txt , complete, as root. Also for later.

(in that 597554 bug) ? Or should I post just the diff from that emerge--info


Reproducible: Always
Comment 1 miro.rovis 2016-11-01 19:52:04 UTC
Created attachment 452100 [details]
Comment 2 miro.rovis 2016-11-01 19:53:12 UTC
Created attachment 452102 [details]
Comment 3 miro.rovis 2016-11-01 19:53:51 UTC
Created attachment 452104 [details]
Comment 4 miro.rovis 2016-11-01 19:54:27 UTC
Created attachment 452106 [details]
Comment 5 miro.rovis 2016-11-01 20:03:37 UTC
I forgot to say that I was able to start Firefox with plain 4.8.4 kernel, after allowing it to repair itself; it complained, offered also Safe Mode, but I chose to let it Refresh itself.

However, it hasn't been a normal run of Firefox. What always has shown normally, now (only on my local Apache2, no way would I normally go online without a gresec-hardened) shows very poorly, the font is completely pale on many pages...

Did they drop some support for some old hardware, like they dropped support for ALSA relatively recently?
Comment 6 miro.rovis 2016-11-14 06:02:35 UTC

*** This bug has been marked as a duplicate of bug 98946 ***
Comment 7 miro.rovis 2016-11-14 06:04:29 UTC

*** This bug has been marked as a duplicate of bug 598593 ***