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
This commit is contained in:
parent
18f4c9db68
commit
8a89ca9425
@ -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);
|
||||
|
Loading…
Reference in New Issue
Block a user