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: [email protected]
Signed-off-by: Hugh Dickins <[email protected]>
Cc: [email protected]
---
fs/exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.26-rc9/fs/exec.c 2008-06-21 08:41:19.000000000 +0100
+++ linux/fs/exec.c 2008-07-10 20:02:25.000000000 +0100
@@ -610,7 +610,7 @@ int setup_arg_pages(struct linux_binprm
bprm->exec -= stack_shift;
down_write(&mm->mmap_sem);
- vm_flags = vma->vm_flags;
+ vm_flags = VM_STACK_FLAGS;
/*
* Adjust stack execute permissions; explicitly enable for
On 10 Jul 2008 at 21:19, Hugh Dickins wrote:
> 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.
alternatively, if there's a concern of stack_vma->vm_flags manipulation
during execve (maybe not now, but in the future or in non-ELF formats
that also want to rely on personality bits), you could opt for a safer
vm_flags = vma->vm_flags | (VM_STACK_FLAGS & (VM_EXEC | VM_MAYEXEC));
to just recompute the exec rights related bits.
> Reported-by: [email protected]
> Signed-off-by: Hugh Dickins <[email protected]>
> Cc: [email protected]
> ---
>
> fs/exec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.26-rc9/fs/exec.c 2008-06-21 08:41:19.000000000 +0100
> +++ linux/fs/exec.c 2008-07-10 20:02:25.000000000 +0100
> @@ -610,7 +610,7 @@ int setup_arg_pages(struct linux_binprm
> bprm->exec -= stack_shift;
>
> down_write(&mm->mmap_sem);
> - vm_flags = vma->vm_flags;
> + vm_flags = VM_STACK_FLAGS;
>
> /*
> * Adjust stack execute permissions; explicitly enable for
>
On Thu, 10 Jul 2008, [email protected] wrote:
> On 10 Jul 2008 at 21:19, Hugh Dickins wrote:
>
> > 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.
>
> alternatively, if there's a concern of stack_vma->vm_flags manipulation
> during execve (maybe not now, but in the future or in non-ELF formats
> that also want to rely on personality bits), you could opt for a safer
>
> vm_flags = vma->vm_flags | (VM_STACK_FLAGS & (VM_EXEC | VM_MAYEXEC));
>
> to just recompute the exec rights related bits.
True. It was a concern that crossed my mind (I was thinking particularly
of the VM_ACCOUNT flag, which gets added in once we deal with a writable
private mapping, but is set from the start here anyway), but I don't
think it's worth changing my
> > - vm_flags = vma->vm_flags;
> > + vm_flags = VM_STACK_FLAGS;
now that's already there in Linus' tree. If a VM_flag gets added that
changes the picture, it might even need your line above to be changed.
Hugh