From ebff66b3c3314b29a295f6ea6276e74cec47c841 Mon Sep 17 00:00:00 2001 From: Kyle Evans Date: Fri, 12 Jun 2020 18:13:32 +0000 Subject: [PATCH] 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 X-MFC-With: r361996 --- lib/libc/gen/posix_spawn.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/lib/libc/gen/posix_spawn.c b/lib/libc/gen/posix_spawn.c index 581d057c82ed..0bca52811e30 100644 --- a/lib/libc/gen/posix_spawn.c +++ b/lib/libc/gen/posix_spawn.c @@ -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;