On Mon, Dec 03, 2018, Philip Guenther wrote: [thanks for the analysis/explanation!]
> And now this kbind() call blows up: the address is not on the original > thread's stack but in one of those mmap()s...but those mmap()s were not > marked as stacks by including MAP_STACK. To quote the "Security > improvements" section of https://www.openbsd.org/64.html > * Implemented MAP_STACK option for mmap(2). At pagefaults and > syscalls the kernel will check that the stack pointer points > to MAP_STACK memory, which mitigates against attacks using > stack pivots. Hmm, I read that and it seems I misunderstood it -- I will give this a try. However, here's the weird part: there's a compile time switch not to use mmap(2) but malloc(2) and I selected that option in one of my test because of that note: that version also crashed, hence I was under the impression that MAP_STACK couldn't be the problem. static char *_st_new_stk_segment(int size) { #ifdef MALLOC_STACK void *vaddr = malloc(size); #else int mmap_flags = MAP_PRIVATE; void *vaddr; mmap_flags |= MAP_ANON; vaddr = mmap(NULL, size, PROT_READ | PROT_WRITE, mmap_flags, zero_fd, 0); if (vaddr == (void *)MAP_FAILED) return NULL; #endif /* MALLOC_STACK */ return (char *)vaddr; }
