From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id 051D83858D37; Mon, 29 Aug 2022 10:26:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 051D83858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1661768782; bh=kChMiH/K2qpKi/KnEYLYnNZgdQZ2HZPpWr0bZs28eSA=; h=From:To:Subject:Date:From; b=byxdrPTk1HGEweDUmCrTtU9DjGtsW5ImR6HL5PmBGh0WQbNRQSeyv5C0HL7bDmXEj u5+wP+H2z7SJ9z9Re0gpBwVzo8ILpDTJSr9O7wvVeNeednRoSwr8Bxfb0MYUXrzFH0 UHgrhHXQ6VUWLHtD5geo7uew3vdd/7+mvfiEl32o= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Corinna Vinschen To: cygwin-cvs@sourceware.org Subject: [newlib-cygwin] Cygwin: fork: fix a potential hang in fork X-Act-Checkin: newlib-cygwin X-Git-Author: Corinna Vinschen X-Git-Refname: refs/heads/master X-Git-Oldrev: f59ff93046341e688bc36ea81bddd60eea405e21 X-Git-Newrev: 717c36c0a4e387a73146c1181b7b89f091176e85 Message-Id: <20220829102622.051D83858D37@sourceware.org> Date: Mon, 29 Aug 2022 10:26:22 +0000 (GMT) List-Id: https://sourceware.org/git/gitweb.cgi?p=3Dnewlib-cygwin.git;h=3D717c36c0a4e= 387a73146c1181b7b89f091176e85 commit 717c36c0a4e387a73146c1181b7b89f091176e85 Author: Corinna Vinschen Date: Mon Aug 29 12:25:24 2022 +0200 Cygwin: fork: fix a potential hang in fork =20 while debugging a problem introduced in commit 63b503916d42 ("Cygwin: tls_pathbuf: Use Windows heap") a hang in fork was encountered using the original implementation of tls_pathbuf: =20 Using tmp_pathbuf inside the code block guarded by __malloc_trylock may call malloc from tmp_pathbuf::w_get and thus trying to lock an exclusive SRW lock recursively, which results in a deadlock. =20 Allocate a small SECURITY_ATTRIBUTES block on the stack rather than allocating a 64K tmp_pathbuf. This avoids the potential malloc call. =20 Drop the __malloc_trylock call entirely. There must not be a malloc call inside the frok::parent block guarded by __malloc_lock, and just trying to lock is too dangerous inside fork while other threads might actually chage the content of the heap. Additionally, add a comment frowning on malloc usage inside tis code block. =20 Fixes: 44a79a6eca3d ("Cygwin: convert malloc lock to SRWLOCK") Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/fork.cc | 8 +++++--- winsup/cygwin/local_includes/cygmalloc.h | 1 - 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/winsup/cygwin/fork.cc b/winsup/cygwin/fork.cc index e4931a286..e553c015a 100644 --- a/winsup/cygwin/fork.cc +++ b/winsup/cygwin/fork.cc @@ -296,7 +296,10 @@ frok::parent (volatile char * volatile stack_here) si.lpReserved2 =3D (LPBYTE) &ch; si.cbReserved2 =3D sizeof (ch); =20 - bool locked =3D __malloc_trylock (); + /* NEVER, EVER, call a function which in turn calls malloc&friends while= this + malloc lock is active! */ + __malloc_lock (); + bool locked =3D true; =20 /* Remove impersonation */ cygheap->user.deimpersonate (); @@ -308,8 +311,7 @@ frok::parent (volatile char * volatile stack_here) =20 ch.silentfail (!*with_forkables); /* fail silently without forkables */ =20 - tmp_pathbuf tp; - PSECURITY_ATTRIBUTES sa =3D (PSECURITY_ATTRIBUTES) tp.w_get (); + PSECURITY_ATTRIBUTES sa =3D (PSECURITY_ATTRIBUTES) alloca (1024); if (!sec_user_nih (sa, cygheap->user.saved_sid (), well_known_authenticated_users_sid, PROCESS_QUERY_LIMITED_INFORMATION)) diff --git a/winsup/cygwin/local_includes/cygmalloc.h b/winsup/cygwin/local= _includes/cygmalloc.h index 73a2f060b..5e1fe8154 100644 --- a/winsup/cygwin/local_includes/cygmalloc.h +++ b/winsup/cygwin/local_includes/cygmalloc.h @@ -32,7 +32,6 @@ extern "C" void __set_ENOMEM (); #elif defined (__INSIDE_CYGWIN__) =20 # define __malloc_lock() AcquireSRWLockExclusive (&mallock) -# define __malloc_trylock() TryAcquireSRWLockExclusive (&mallock) # define __malloc_unlock() ReleaseSRWLockExclusive (&mallock) extern SRWLOCK NO_COPY mallock; void malloc_init ();