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
This commit is contained in:
Kyle Evans 2020-06-12 18:13:32 +00:00
parent 13dca1937f
commit ebff66b3c3
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=362111

View File

@ -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;