Skip to content
  • Hugh Dickins's avatar
    96a8e13e
    exec: fix stack excutability without PT_GNU_STACK · 96a8e13e
    Hugh Dickins authored
    
    
    Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
    exec'ing an ELF without a PT_GNU_STACK program header should default to an
    executable stack; but this got broken by the unlimited argv feature because
    stack vma is now created before the right personality has been established:
    so breaking old binaries using nested function trampolines.
    
    Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
    vm_flags used to be set, before the mprotect_fixup.  Checking through
    our existing VM_flags, none would have changed since insert_vm_struct:
    so this seems safer than finding a way through the personality labyrinth.
    
    Reported-by: default avatar <pageexec@freemail.hu>
    Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
    Cc: stable@kernel.org
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    96a8e13e
    exec: fix stack excutability without PT_GNU_STACK
    Hugh Dickins authored
    
    
    Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
    exec'ing an ELF without a PT_GNU_STACK program header should default to an
    executable stack; but this got broken by the unlimited argv feature because
    stack vma is now created before the right personality has been established:
    so breaking old binaries using nested function trampolines.
    
    Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
    vm_flags used to be set, before the mprotect_fixup.  Checking through
    our existing VM_flags, none would have changed since insert_vm_struct:
    so this seems safer than finding a way through the personality labyrinth.
    
    Reported-by: default avatar <pageexec@freemail.hu>
    Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
    Cc: stable@kernel.org
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Loading