The following test case produces a segfault with ghc-9.4.5 on Mac. The version of process is 1.6.16.0.

import Control.Monad
import System.Process
main :: IO ()
main = void $ createProcess $ CreateProcess
    { child_group = Nothing
    , child_user = Nothing
    , close_fds = False
    , cmdspec = RawCommand "env" []
    , create_group = True
    , create_new_console = False
    , cwd = Nothing
    , delegate_ctlc = False
    , detach_console = False
    , env = Just [("PATH", "/bin:/usr/bin")]
    , new_session = False
    , std_err = Inherit
    , std_in = Inherit
    , std_out = Inherit
    , use_process_jobs = False
    }

I used the copy of ghc installed by stack:

$ ~/.stack/programs/x86_64-osx/ghc-9.4.5/bin/runghc TestCase.hs
Segmentation fault: 11
$ ~/.stack/programs/x86_64-osx/ghc-9.4.5/bin/ghc-pkg list process
~/.stack/programs/x86_64-osx/ghc-9.4.5/lib/ghc-9.4.5/lib/package.conf.d
    process-1.6.16.0

It's crashing in strlen:

$ lldb TestCase
(lldb) target create "TestCase"
Current executable set to '~/portal-suite/devtools/gabe/test/TestCase' (x86_64).
(lldb) r
Process 65154 launched: '~/portal-suite/devtools/gabe/test/TestCase' (x86_64)
Process 65154 stopped
* thread #1, name = 'ghc_ticker', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007ff8189646b2 libsystem_platform.dylib`_platform_strlen + 18
libsystem_platform.dylib`:
->  0x7ff8189646b2 <+18>: pcmpeqb (%rdi), %xmm0
    0x7ff8189646b6 <+22>: pmovmskb %xmm0, %esi
    0x7ff8189646ba <+26>: andq   $0xf, %rcx
    0x7ff8189646be <+30>: orq    $-0x1, %rax
Target 0: (TestCase) stopped.
(lldb) p $rdi
(unsigned long) $0 = 0
(lldb) bt
* thread #1, name = 'ghc_ticker', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007ff8189646b2 libsystem_platform.dylib`_platform_strlen + 18
    frame #1: 0x000000010000d0ae TestCase`find_executable + 142
    frame #2: 0x000000010000c873 TestCase`do_spawn_fork + 99
    frame #3: 0x000000010000c6bd TestCase`runInteractiveProcess + 429
    frame #4: 0x0000000100010ce1 TestCase`Lc5h0_info + 113

Although the backtrace says it's in find_executable, I think it's actually in find_in_search_path which has been inlined by the C compiler:

static char *find_in_search_path(char *working_dir, char *search_path, const char *filename) {
    int workdir_len = strlen(working_dir);

It doesn't crash when the Haskell cwd value is a Just.