Fedora Account System
Red Hat Associate
Red Hat Customer
Running Firefox with shadow stack support enabled on a system with appropriate support (11th or newer gen Intel CPU) leads to an error at startup when the firefox runtime attempts to load /usr/lib64/firefox/libgkcodecs.so: $ GLIBC_TUNABLES=glibc.cpu.hwcaps=SHSTK /usr/bin/firefox XPCOMGlueLoad error for file /usr/lib64/firefox/libgkcodecs.so: /usr/lib64/firefox/libgkcodecs.so: rebuild shared object with SHSTK support enabled Couldn't load XPCOM. Some background for why this bug is being filed and marked with a "High" severity: We (the glibc team) are planning to enable Shadow Stack protection by default in Fedora 45, and this bug report is a result of early testing. Here is a WIP/draft Fedora System-Wide Change Proposal: https://fedoraproject.org/wiki/Changes/ShadowStack In the case of Firefox, it appears that while the primary firefox binary and objects it directly links against are built with SHSTK support (and therefore the program is started by the loader with SHSTK support on, some objects that are loaded by firefox *after* program startup via dlopen are not. Here is a more complete report of which objects are built with and which without support: NO /usr/lib64/firefox/crashhelper NO /usr/lib64/firefox/crashreporter YES /usr/lib64/firefox/firefox YES /usr/lib64/firefox/firefox-bin YES /usr/lib64/firefox/glxtest YES /usr/lib64/firefox/gmp-clearkey/0.1/libclearkey.so NO /usr/lib64/firefox/libgkcodecs.so YES /usr/lib64/firefox/liblgpllibs.so YES /usr/lib64/firefox/libmozavcodec.so YES /usr/lib64/firefox/libmozavutil.so YES /usr/lib64/firefox/libmozgtk.so YES /usr/lib64/firefox/libmozinference.so YES /usr/lib64/firefox/libmozsandbox.so YES /usr/lib64/firefox/libmozsqlite3.so YES /usr/lib64/firefox/libmozwayland.so NO /usr/lib64/firefox/libxul.so YES /usr/lib64/firefox/pingsender YES /usr/lib64/firefox/vaapitest As far as I can tell, this is due to some asm files that are not annotated. There are some notes in the Documentation section of the change proposal on how to identify and fix issues such as these, although it does not apply directly to nasm: https://fedoraproject.org/wiki/Changes/ShadowStack#Documentation Reproducible: Always Steps to Reproduce: 1. Use a machine with SHSTK support: cat /proc/cpuinfo | grep shstk 2. Run firefox with SHSTK on: GLIBC_TUNABLES=glibc.cpu.hwcaps=SHSTK /usr/bin/firefox Actual Results: XPCOMGlueLoad error for file /usr/lib64/firefox/libgkcodecs.so: /usr/lib64/firefox/libgkcodecs.so: rebuild shared object with SHSTK support enabled Couldn't load XPCOM. Expected Results: Firefox does not crash, and runs with SHSTK support on
That's something we may want to bring upstream at bugzilla.mozilla.org. Is that gcc/glib specific? Does it affects Mozilla builds too? https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries Thanks.
(In reply to Martin Stransky from comment #1) > That's something we may want to bring upstream at bugzilla.mozilla.org. Is > that gcc/glib specific? Does it affects Mozilla builds too? > https://fedoraproject.org/wiki/ > How_to_debug_Firefox_problems#Testing_Mozilla_binaries It does not impact Mozilla binaries because they do not use the Fedora build flags. The crash will go way if you remove -fcf-protection from the build flags. This way, the main Firefox binary will be marked as incompatible, and the process will remain in legacy mode (shadow stack is never turned on).
The JIT is the major blocker here and until upstream fixes it (https://bugzilla.mozilla.org/show_bug.cgi?id=1902244), we cannot have shadow stack protection for Firefox. In the meanwhile, we should drop the -fcf-protection flag during Firefox builds by adjusting the spec file.
Added to firefox-152.0.4-3.
FEDORA-2026-0cd8472f57 (firefox-152.0.4-3.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-0cd8472f57
FEDORA-2026-0cd8472f57 (firefox-152.0.4-3.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.