linux-kernel - Re: [Bug 11063][PATCH] exec: fix stack excutability without PT_GNU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0807111203140.19456@blonde.site>
Date:	Fri, 11 Jul 2008 12:15:06 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	pageexec@...email.hu
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ollie Wild <aaw@...gle.com>, bugme-daemon@...zilla.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Roland McGrath <roland@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, stable@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Bug 11063][PATCH] exec: fix stack excutability without PT_GNU_STACK

On Thu, 10 Jul 2008, pageexec@...email.hu 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/