On Tue, Dec 04, 2018 at 02:33:40AM -0800, Claus Assmann wrote:
> 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.
malloc(3) uses mmap without MAP_STACK flag, so you'll end up with memory
not marked MAP_STACK in both cases.
Define MALLOC_STACK and add MAP_STACK to the flags,
-Otto
>
>
> 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;
> }
>
