NetBSD Problem Report #59237

From www@netbsd.org  Sun Mar 30 23:14:15 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id B590E1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 30 Mar 2025 23:14:14 +0000 (UTC)
Message-Id: <20250330231413.28A761A923F@mollari.NetBSD.org>
Date: Sun, 30 Mar 2025 23:14:13 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: postfork mutex audit: mutex_init, not mutex_unlock
X-Send-Pr-Version: www-1.0

>Number:         59237
>Category:       lib
>Synopsis:       postfork mutex audit: mutex_init, not mutex_unlock
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 30 23:15:00 +0000 2025
>Last-Modified:  Sun Mar 30 23:35:44 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetBSD Postforkation Lock
>Environment:
>Description:
Various pthread_atfork handlers use the following idiom:

prefork: mutex_lock(something)
postfork_parent: mutex_unlock(something)
postfork_child: mutex_unlock(something)

The mutex_unlock in the child is incorrect and may lead to hangs, crashes, or boogervorous demons.  Suppose this happens:

thread 1                thread 2
--------                --------
fork() library routine
   prefork
      mutex_lock(&lock)
                        mutex_lock(&lock) queues self for lock
   real fork syscall

When the process is actually forked via the real fork syscall, thread 2 may hold the internal spin lock or have itself on the internal queue.  So when the postfork_child handler runs, it will find a mutex in an inconsistent _internal_ state.
>How-To-Repeat:
code inspection
probably testable with a lot of patience for someone to win a race
>Fix:
Change postfork_child handlers to use mutex_init, not mutex_unlock -- that will clear any state potentially held by other threads, which don't exist in the child anyway, so there's nothing to be lost by forgetting about them.

_malloc_postfork_child:
[ ] external/bsd/jemalloc.old/dist/src/jemalloc.c
[ ] external/bsd/jemalloc/dist/src/jemalloc.c
[ ] external/gpl2/libmalloc/lib/combined.c
[ ] lib/libbsdmalloc/malloc.c
[ ] lib/libc/stdlib/jemalloc.c
[ ] lib/libc/stdlib/malloc.c

pthread_atfork:
[ ] crypto/external/bsd/openssl.old/dist/crypto/threads_pthread.c
[ ] external/bsd/jemalloc.old/dist/src/jemalloc.c
[ ] external/bsd/jemalloc/dist/src/jemalloc.c
[ ] external/cddl/osnet/dist/lib/libuutil/common/uu_misc.c
[ ] external/gpl3/gcc.old/dist/libsanitizer/lsan/lsan_interceptors.cc
[ ] external/gpl3/gcc/dist/libphobos/libdruntime/core/thread/osthread.d
[ ] external/gpl3/gcc/dist/libsanitizer/asan/asan_interceptors.cpp
[ ] external/gpl3/gcc/dist/libsanitizer/hwasan/hwasan_linux.cpp
[ ] external/gpl3/gcc/dist/libsanitizer/lsan/lsan_interceptors.cpp
[ ] external/gpl3/gcc/dist/libsanitizer/tsan/tsan_interceptors_posix.cpp
[ ] external/lgpl2/userspace-rcu/dist/doc/rcu-api.md [api function]
[ ] external/lgpl2/userspace-rcu/dist/tests/regression/test_urcu_fork.c
[ ] external/mit/libuv/dist/src/threadpool.c
[ ] external/mit/libuv/dist/src/unix/os390-syscalls.c
[ ] external/mit/libuv/dist/src/unix/signal.c
[ ] lib/libc/gen/arc4random.c
[ ] lib/libpthread/pthread.c
[ ] lib/libpthread/pthread_tsd.c

>Release-Note:

>Audit-Trail:

>Unformatted:

Home	PR Database Search