Bugzilla

Used IA to investigate, got this results. May it be caused by system NSS?

Root cause: UUID PRNG not re-seeded after process fork
     
  The log proves it:
  - Child 230494 generates UUID {90a0dda9-...} via CreateSourceInternal(new UUID) at this=7f2561152580
  - Child 230517 generates the exact same UUID {90a0dda9-...} via CreateSourceInternal(new UUID) at the same this=7f2561152580

  Same UUID + same heap address = these two processes were forked from a common ancestor (fork server) and the PRNG state was duplicated without re-seeding.

  Looking at the code, GenerateUUIDInPlace tries NSS first (PK11_GenerateRandomOnSlot) on the main thread. NSS uses a userspace PRNG (Fortuna). After fork, if the NSS PRNG isn't re-seeded,
  both children produce identical UUID sequences.

  The OS fallback (getrandom()) would be fork-safe since it's a syscall, but it's only used when NSS isn't available.

  Are you using the fork server? You can check with:
  # Check if fork server is enabled
  grep -i forkserver about:config  # or:
  echo $MOZ_FORCE_DISABLE_E10S

  Or check dom.ipc.forkserver.enable in about:config.

  Possible mitigations to test:
  1. Disable fork server: set dom.ipc.forkserver.enable to false in about:config
  2. Or set env MOZ_FORK_SERVER=0 before launching

Looks like dom.ipc.forkserver.enable does the trick.

Used IA to investigate, got this results. May it be caused by system NSS?

Root cause: UUID PRNG not re-seeded after process fork
     
  The log proves it:
  - Child 230494 generates UUID {90a0dda9-...} via CreateSourceInternal(new UUID) at this=7f2561152580
  - Child 230517 generates the exact same UUID {90a0dda9-...} via CreateSourceInternal(new UUID) at the same this=7f2561152580

  Same UUID + same heap address = these two processes were forked from a common ancestor (fork server) and the PRNG state was duplicated without re-seeding.

  Looking at the code, GenerateUUIDInPlace tries NSS first (PK11_GenerateRandomOnSlot) on the main thread. NSS uses a userspace PRNG (Fortuna). After fork, if the NSS PRNG isn't re-seeded,
  both children produce identical UUID sequences.

  The OS fallback (getrandom()) would be fork-safe since it's a syscall, but it's only used when NSS isn't available.

  Are you using the fork server? You can check with:

  Check dom.ipc.forkserver.enable in about:config.

  Possible mitigations to test:
  1. Disable fork server: set dom.ipc.forkserver.enable to false in about:config
  2. Or set env MOZ_FORK_SERVER=0 before launching

Looks like dom.ipc.forkserver.enable does the trick.