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;
No comments:
Post a Comment