Works fine on a laptop

Interesting if disabling the dom.ipc.forkserver.enable configuration property is only a temporary workaround and will be enabled again after a proper fix sometime in a future?

I've been trying to get some kind of patch developed that would properly address the problem, but no luck thus far.

Latest try is building now: https://copr.fedorainfracloud.org/coprs/bojan/firefox/build/10767044/

If you are keen to test. Keep your expectations low - it will likely not work.

Is this disabled in upstream as well or just an issue with Fedora builds?

Fedora specific.

Following Mozilla ticket seems tracking this issue:

• https://bugzilla.mozilla.org/show_bug.cgi?id=2056509

I guess when it will be properly fixed the dom.ipc.forkserver.enable == false workaround in the Fedora package will be disabled.

@bojan thanks for trying to fix it properly in the upstream.

My copr build completed and I am not seeing crashes. Forkserver is set to true in about:config. Feel free to test. For the record, this was the patch I used:

--- a/xpcom/base/nsID.cpp
+++ b/xpcom/base/nsID.cpp
@@ -6,47 +6,13 @@

 #include <limits.h>

-#include "MainThreadUtils.h"
 #include "mozilla/Assertions.h"
 #include "mozilla/RandomNum.h"
 #include "mozilla/Sprintf.h"
-#include "nss.h"
-#include "ScopedNSSTypes.h"
-
-[[nodiscard]] static bool GenerateRandomBytesFromNSS(void* aBuffer,
-                                                     size_t aLength) {
-  MOZ_ASSERT(aBuffer);
-
-  // Bounds check that we can safely truncate size_t `aLength` to an int.
-  if (aLength == 0 || aLength > INT_MAX) {
-    MOZ_ASSERT_UNREACHABLE("Bad aLength");
-    return false;
-  }
-  int len = static_cast<int>(aLength);
-
-  // Only try to use NSS on the main thread.
-  if (!NS_IsMainThread() || !NSS_IsInitialized()) {
-    return false;
-  }
-
-  mozilla::UniquePK11SlotInfo slot(PK11_GetInternalSlot());
-  if (!slot) {
-    MOZ_ASSERT_UNREACHABLE("Null slot");
-    return false;
-  }
-
-  SECStatus srv = PK11_GenerateRandomOnSlot(
-      slot.get(), static_cast<unsigned char*>(aBuffer), len);
-  MOZ_ASSERT(srv == SECSuccess);
-  return (srv == SECSuccess);
-}

 nsresult nsID::GenerateUUIDInPlace(nsID& aId) {
-  // Firefox needs to generate some UUIDs before NSS has been initialized. We
-  // prefer NSS's RNG, but if NSS is not available yet or returns an error, fall
-  // back to MFBT's GenerateRandomBytes().
-  if (!GenerateRandomBytesFromNSS(&aId, sizeof(nsID)) &&
-      !mozilla::GenerateRandomBytesFromOS(&aId, sizeof(nsID))) {
+  // Always use OS for RNG
+  if (!mozilla::GenerateRandomBytesFromOS(&aId, sizeof(nsID))) {
     MOZ_ASSERT_UNREACHABLE("GenerateRandomBytesFromOS() failed");
     return NS_ERROR_NOT_AVAILABLE;
   }

@bojan your patch is basically a switch from NSS to OS native RND, isn't it? Maybe a better fix is already done in the NSS upstream project? Currently Fedora 44 uses NSS version 3.125, but there is a newer NSS 3.126 version with many fixes in its release notes:

https://firefox-source-docs.mozilla.org/security/nss/releases/nss_3_126.html

The original code of the GenerateRandomBytesFromNSS and of its usage (that your patch removes) is 5 years old:

https://github.com/mozilla-firefox/firefox/commit/cc16e605e1e070ad1e147e9a4aca86c391c2ba35

Interesting why it started to trigger this crash just now?

Yes. First, I tried the AI suggestion of injecting more randomness into NSS, but that didn't work (I am not overly familiar with NSS, so I had to rely on AI to tell me what's what here). Anyway, finally decided to just use OS randomness and that seems to be better in this situation.

Maybe this has something to do with NSS being a separate library in Fedora as @stransky suggested. In any event, it seems that this forking behaviour is new in this release (or at least different), so maybe that surfaced some subtleties.

BTW, just to be sure, I checked again and it seems to me that Firefox 153.0 source comes bundled with NSS 3.125, not 3.126. And yet, when built with bundled NSS, everything works.

$ echo $(<firefox-153.0-build/firefox-153.0/security/nss/TAG-INFO)
NSS_3_125_RTM

Interesting what @fkrenzel would say? He is the maintainer of the NSS Fedora package.

Maybe one the patches of the NSS Fedora package is wrong or outdated and now triggers this issue in Firefox? Otherwise how could it be that the original upstream's build of Firefox doesn't have such issue and doesn't disable dom.ipc.forkserver.enable by default?

I see in https://src.fedoraproject.org/rpms/nss/tree/f44 many patches originally made for very old versions of NSS.

And yet, when built with bundled NSS, everything works.

This sounds suspicious.

All very valid questions, to which I do not have a good answer. My gdb session in https://bugzilla.mozilla.org/show_bug.cgi?id=2056509 shows identical UUIDs, but why exactly that is, I still do not know. AI theorised that it is because forked children start with identical memory footprints, ergo, their random generators generate identical stuff. But, how exactly that would only happen with system NSS, not sure.

When discussed with AI this issue and the upstream change of how destructor of the ForkServerLauncher class is now defined I got following interesting conclusion. AI guess the root of this issue is Static Initialization Order Fiasco (SIOF) and it looks like it should be fixed by the upstream. Following text is AI generated:

The Issue: Fork Server + NSS RNG State Duplication

Firefox uses a Fork Server on Linux to speed up the launching of new content processes. When a new process is needed, the main process asks the Fork Server to call fork(). The child process inherits the exact memory space of the Fork Server.

The bug occurs because the NSS (Network Security Services) library initializes its Random Number Generator (RNG) to generate UUIDs. If the NSS RNG is initialized before the fork() happens, the child process inherits the exact same RNG state. As a result, all child processes spawn with identical entropy, leading them to generate duplicate UUIDs.

Why Clang (Upstream) works, but GCC (Fedora) fails

This is a classic Static Initialization Order Fiasco (SIOF). C++ does not guarantee the order in which global/static objects are initialized across different translation units.

• Clang (Mozilla build): Clang's compilation and linking algorithms (especially with LTO and LLD) arrange the .init_array sections in a way that happens to delay NSS initialization until after the fork occurs.
• GCC (Fedora build): GCC and GNU ld arrange object files and initializer sections differently. In Fedora's build, NSS was initialized before the Fork Server began spawning children. (The use of out-of-line = default destructors in .cpp files affects vtable emission and linker ordering, indirectly contributing to this difference).

Relying on compiler linking order for correct runtime behavior is a latent bug.

How to Fix It Properly

The fix must be deterministic and explicitly handle the fork() boundary, rather than relying on compilation order. There are three standard approaches:

1. Explicit Re-seeding After fork() (Best Practice): Immediately after fork() returns 0 (indicating we are in the child process), explicitly call an NSS API to fetch fresh entropy from the OS (e.g., via getrandom() or /dev/urandom) and re-seed the PRNG. cpp pid_t pid = fork(); if (pid == 0) { // We are in the child process NSS_ReinitializeRNG(); // Fetch fresh entropy and re-seed // ... continue execution }

2. Using pthread_atfork(): Register a handler at program startup that automatically re-seeds the RNG in the child process whenever a fork() occurs. cpp pthread_atfork(nullptr, nullptr, []() { // Called automatically in the child process after fork() NSS_ReinitializeRNG(); });

3. Lazy Initialization: Prevent NSS from initializing globally before main() or before the fork. Use lazy initialization (e.g., a function with a local static variable) so the RNG is only initialized the first time a UUID is actually requested—which should naturally happen after the child process has started its independent execution.

I think the fix (calling GenerateRandomBytesFromOS) @bojan has made could be used as a temporary solution until a proper fix from the upstream isn't available. I think it's better than just to disable the dom.ipc.forkserver.enable properly by default.

@rosti, @stransky: in case you'd like to follow/use: https://src.fedoraproject.org/rpms/firefox/pull-request/106

@rosti: @anotheruser threw a bit of a spanner into the AI works with the comment in this update: FEDORA-2026-bf44fd38de. Apparently, it also happens in clang builds.

Thanks for the update, but it changed my default "browser language" again.

153.0.1 is out: https://www.firefox.com/en-US/firefox/153.0.1/releasenotes/

I do not have permission to upload Firefox tarballs to koji build storage, so cannot update https://src.fedoraproject.org/rpms/firefox/pull-request/106, which would produce scratch builds of .1, but if you are keen to try: https://copr.fedorainfracloud.org/coprs/bojan/firefox/builds. The copr build has ForkServer enabled using the upstream patch.

@bojan, pls consider also those two patches

1. fix for vulkan_video_decoding ( vulkan_copy) ( verified in my build ) https://phabricator.services.mozilla.com/D314530 ( applies w/o changes to release branch) I used an older revision of the patch, though.

2. enable vulkan_video decoding in wayland with active RDD sandbox https://phabricator.services.mozilla.com/D314604 needs small change to apply on releae branch, I need to verify that this works.
   ths should obsolete MOZ_DISABLE_RDD_SANDBOX=1

ignore the second patch, it falls back to CPU decoding, previously video would hang. FF153 requires the MOZ_DISABLE_RDD_SANDBOX=1

I wonder if this package needs more maintainers. It looks like no builds were triggered for 153.0.1 yet and it carries quite a few fixes. Is anyone able to do that?

@markec maybe @stransky is waiting for nss-3.126.0-1 to be released for Fedora 44? Currently available only for the upcoming Fedora 45 and eln158, although the f44 branch of NSS already contains this update:

https://src.fedoraproject.org/rpms/nss/commits/f44

Maybe tomorrow new builds will happen?

:fingercrossed:

Looks like we have new nss for F44 build and fixes quite a lot of bugs :)

FEDORA-2026-d604bc1848

I've created a new pull request with Firefox 153.0.1 upstream version and dependency to the new NSS 3.126.0 with a better workaround of mzbz#2056004 and the previously done workaround of dom.ipc.forkserver.enable = false removed.

https://src.fedoraproject.org/rpms/firefox/pull-request/107

I'm not a Firefox package maintainer, so the new archives have not been uploaded to Fedora’s lookaside cache. A maintainer (@stransky) should upload or regenerate:

• firefox-153.0.1.source.tar.xz
• firefox-langpacks-153.0.1-20260802.tar.xz (regenerate)

Just FYI, ff 153.0-3 with new NSS 3.126.0 (hit stable today) also works fine with re-enabled dom.ipc.forkserver.enable

↑

I was on PTO last week. Will update the builds.