svn commit: r362111 - head/lib/libc/gen

Kyle Evans kevans at FreeBSD.org
Fri Jun 12 18:13:32 UTC 2020


Author: kevans
Date: Fri Jun 12 18:13:32 2020
New Revision: 362111
URL: https://svnweb.freebsd.org/changeset/base/362111

Log:
  posix_spawn: fix for some custom allocator setups
  
  libc cannot assume that aligned_alloc and free come from jemalloc, or that
  any application providing its own malloc and free is actually providing
  aligned_alloc.
  
  Switch back to malloc and just make sure we're passing a properly aligned
  stack into rfork_thread, as an application perhaps can't reasonably replace
  just malloc or just free without headaches.
  
  This unbreaks ksh93 after r361996, which provides malloc/free but no
  aligned_alloc.
  
  Reported by:	freqlabs
  Diagnosed by:	Andrew Gierth <andrew_tao173.riddles.org.uk>
  X-MFC-With:	r361996

Modified:
  head/lib/libc/gen/posix_spawn.c

Modified: head/lib/libc/gen/posix_spawn.c
==============================================================================
--- head/lib/libc/gen/posix_spawn.c	Fri Jun 12 17:48:12 2020	(r362110)
+++ head/lib/libc/gen/posix_spawn.c	Fri Jun 12 18:13:32 2020	(r362111)
@@ -276,9 +276,19 @@ do_posix_spawn(pid_t *pid, const char *path,
 		stacksz += MAX(3, cnt + 2) * sizeof(char *);
 		stacksz = PSPAWN_STACK_ALIGN(stacksz);
 	}
-	stack = aligned_alloc(PSPAWN_STACK_ALIGNMENT, stacksz);
+
+	/*
+	 * aligned_alloc is not safe to use here, because we can't guarantee
+	 * that aligned_alloc and free will be provided by the same
+	 * implementation.  We've actively hit at least one application that
+	 * will provide its own malloc/free but not aligned_alloc leading to
+	 * a free by the wrong allocator.
+	 */
+	stack = malloc(stacksz);
 	if (stack == NULL)
 		return (ENOMEM);
+	stacksz = (((uintptr_t)stack + stacksz) & ~PSPAWN_STACK_ALIGNBYTES) -
+	    (uintptr_t)stack;
 #endif
 	psa.path = path;
 	psa.fa = fa;


More information about the svn-src-head mailing list