From 8a89ca94257bdcfa040834adab1f18b40a3e76f5 Mon Sep 17 00:00:00 2001 From: Konstantin Belousov Date: Sun, 25 Jun 2017 23:16:37 +0000 Subject: [PATCH] For now, allow mprotect(2) over the guards to succeed regardless of the requested protection. The syscall returns success without changing the protection of the guard. This is consistent with the current mprotect(2) behaviour on the unmapped ranges. More important, the calls performed by libc and libthr to allow execution of stacks, if requested by the loaded ELF objects, do the expected change instead of failing on the grow space guard. Reviewed by: alc, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week --- sys/vm/vm_map.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 223678ec6dbc..7b4a86dffd89 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -2003,6 +2003,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, */ for (current = entry; current != &map->header && current->start < end; current = current->next) { + if ((current->eflags & MAP_ENTRY_GUARD) != 0) + continue; if (current->eflags & MAP_ENTRY_IS_SUB_MAP) { vm_map_unlock(map); return (KERN_INVALID_ARGUMENT);