title: =www-client/firefox-49.0 segfaults with >=media-libs/mesa-13.0.0_rc1 on >=4.4.8-hardened-r1 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 https-everywhere@eff.org 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. Killed And here, the first batch of syslog goes. Pls. note there will be another which will correspond to my adding of: -PAX_MPROTECT to 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. HERE: firefox-49_161101_1126_syslog then I changed: /dev/dri/card0 rw to /dev/dri rw in the subject /usr/lib64/firefox and the syslog is that much shorter: HERE: firefox-49_161101_1140_syslog_dri_allowed 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: -PAX_MPROTECT for /usr/lib64/firefox So, no stdout, but this in the syslog: HERE: firefox-49_161101_1738_syslog_-PAX_MPROTECT And I think I also disabled: -PAX_RANDMAP for firefox, to get this: HERE: firefox-49_161101_1850_syslog_-PAX_RANDMAP 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 libGL.so.1.2.0[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 libGL.so.1.2.0[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 libGL.so.1.2.0[380c24ef000+7b000] And also I can tell: # equery b /usr/lib64/libGL.so.1.2.0 * Searching for /usr/lib64/libGL.so.1.2.0 ... media-libs/mesa-13.0.0_rc2 (/usr/lib64/libGL.so.1.2.0) # 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: 4.7.10-hardened-r1 4.4.8-hardened-r1 and I didn't notice any difference. However that's the much that I can tell. Ah, I almost forgot to also note that: # 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 play). 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 mirror. 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 bug: >=sys-kernel/hardened-sources-4.7.6: Kernel panic when starting KVM guests https://bugs.gentoo.org/show_bug.cgi?id=597554 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. https://bugs.gentoo.org/attachment.cgi?id=451296 (in that 597554 bug) ? Or should I post just the diff from that emerge--info there? Regards! Reproducible: Always
Created attachment 452100 [details] firefox-49_161101_1126_syslog
Created attachment 452102 [details] firefox-49_161101_1140_syslog_dri_allowed
Created attachment 452104 [details] irefox-49_161101_1738_syslog_-PAX_MPROTECT
Created attachment 452106 [details] firefox-49_161101_1850_syslog_-PAX_RANDMAP
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?
*** This bug has been marked as a duplicate of bug 98946 ***
*** This bug has been marked as a duplicate of bug 598593 ***
