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
| ||
|
Message-ID: <874jjd6l0g.fsf@email.froward.int.ebiederm.org> Date: Fri, 29 Sep 2023 10:45:35 -0500 From: "Eric W. Biederman" <ebiederm@...ssion.com> To: Sebastian Ott <sebott@...hat.com> Cc: Kees Cook <keescook@...omium.org>, Thomas Weißschuh <linux@...ssschuh.net>, Pedro Falcato <pedro.falcato@...il.com>, Al Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH v4 0/6] binfmt_elf: Support segments with 0 filesz and misaligned starts Sebastian Ott <sebott@...hat.com> writes: > Hello Kees, > > On Thu, 28 Sep 2023, Kees Cook wrote: >> This is the continuation of the work Eric started for handling >> "p_memsz > p_filesz" in arbitrary segments (rather than just the last, >> BSS, segment). I've added the suggested changes: >> >> - drop unused "elf_bss" variable >> - refactor load_elf_interp() to use elf_load() >> - refactor load_elf_library() to use elf_load() >> - report padzero() errors when PROT_WRITE is present >> - drop vm_brk() > > While I was debugging the initial issue I stumbled over the following > - care to take it as part of this series? > > ----->8 > [PATCH] mm: vm_brk_flags don't bail out while holding lock > > Calling vm_brk_flags() with flags set other than VM_EXEC > will exit the function without releasing the mmap_write_lock. > > Just do the sanity check before the lock is acquired. This > doesn't fix an actual issue since no caller sets a flag other > than VM_EXEC. That seems like a sensible patch. Have you by any chance read this code enough to understand what is gained by calling vm_brk_flags rather than vm_mmap without a file? Unless there is a real advantage it probably makes sense to replace the call of vm_brk_flags with vm_mmap(NULL, ...) as binfmt_elf_fdpic has already done. That would allow removing vm_brk_flags and sys_brk would be the last caller of do_brk_flags. Eric > Cc: Andrew Morton <akpm@...ux-foundation.org> > Cc: linux-mm@...ck.org > Signed-off-by: Sebastian Ott <sebott@...hat.com> > --- > mm/mmap.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index b56a7f0c9f85..7ed286662839 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3143,13 +3143,13 @@ int vm_brk_flags(unsigned long addr, unsigned long request, unsigned long flags) > if (!len) > return 0; > > - if (mmap_write_lock_killable(mm)) > - return -EINTR; > - > /* Until we need other flags, refuse anything except VM_EXEC. */ > if ((flags & (~VM_EXEC)) != 0) > return -EINVAL; > > + if (mmap_write_lock_killable(mm)) > + return -EINTR; > + > ret = check_brk_limits(addr, len); > if (ret) > goto limits_failed;
Powered by blists - more mailing lists