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
| ||
|
Date: Wed, 2 Jun 2010 11:40:57 +0900 From: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp> To: David Howells <dhowells@...hat.com> Cc: torvalds@...l.org, akpm@...ux-foundation.org, linux-kernel@...r.kernel.org, Mike Frysinger <vapier@...too.org>, Alexander Viro <viro@...iv.linux.org.uk>, Daisuke HATAYAMA <d.hatayama@...fujitsu.com>, Paul Mundt <lethal@...ux-sh.org> Subject: Re: [PATCH] binfmt_elf_fdpic: Fix clear_user() error handling David Howells <dhowells@...hat.com> wrote: > From: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp> > Thanks for updating, improving, the explanation! Takuya > clear_user() returns the number of bytes that could not be copied rather than > an error code. So we should return -EFAULT rather than directly returning the > results. > > Without this patch, positive values may be returned to elf_fdpic_map_file() > and the following error handlings do not function as expected. > > 1. > ret = elf_fdpic_map_file_constdisp_on_uclinux(params, file, mm); > if (ret < 0) > return ret; > 2. > ret = elf_fdpic_map_file_by_direct_mmap(params, file, mm); > if (ret < 0) > return ret; > > Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp> > Signed-off-by: David Howells <dhowells@...hat.com> > Acked-by: Mike Frysinger <vapier@...too.org> > CC: Alexander Viro <viro@...iv.linux.org.uk> > CC: Andrew Morton <akpm@...ux-foundation.org> > CC: Daisuke HATAYAMA <d.hatayama@...fujitsu.com> > CC: Paul Mundt <lethal@...ux-sh.org> > --- > > fs/binfmt_elf_fdpic.c | 26 +++++++++++--------------- > 1 files changed, 11 insertions(+), 15 deletions(-) > > > diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c > index 2c5f9a0..63039ed 100644 > --- a/fs/binfmt_elf_fdpic.c > +++ b/fs/binfmt_elf_fdpic.c > @@ -990,10 +990,9 @@ static int elf_fdpic_map_file_constdisp_on_uclinux( > > /* clear any space allocated but not loaded */ > if (phdr->p_filesz < phdr->p_memsz) { > - ret = clear_user((void *) (seg->addr + phdr->p_filesz), > - phdr->p_memsz - phdr->p_filesz); > - if (ret) > - return ret; > + if (clear_user((void *) (seg->addr + phdr->p_filesz), > + phdr->p_memsz - phdr->p_filesz)) > + return -EFAULT; > } > > if (mm) { > @@ -1027,7 +1026,7 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params, > struct elf32_fdpic_loadseg *seg; > struct elf32_phdr *phdr; > unsigned long load_addr, delta_vaddr; > - int loop, dvset, ret; > + int loop, dvset; > > load_addr = params->load_addr; > delta_vaddr = 0; > @@ -1127,9 +1126,8 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params, > * PT_LOAD */ > if (prot & PROT_WRITE && disp > 0) { > kdebug("clear[%d] ad=%lx sz=%lx", loop, maddr, disp); > - ret = clear_user((void __user *) maddr, disp); > - if (ret) > - return ret; > + if (clear_user((void __user *) maddr, disp)) > + return -EFAULT; > maddr += disp; > } > > @@ -1164,19 +1162,17 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params, > if (prot & PROT_WRITE && excess1 > 0) { > kdebug("clear[%d] ad=%lx sz=%lx", > loop, maddr + phdr->p_filesz, excess1); > - ret = clear_user((void __user *) maddr + phdr->p_filesz, > - excess1); > - if (ret) > - return ret; > + if (clear_user((void __user *) maddr + phdr->p_filesz, > + excess1)) > + return -EFAULT; > } > > #else > if (excess > 0) { > kdebug("clear[%d] ad=%lx sz=%lx", > loop, maddr + phdr->p_filesz, excess); > - ret = clear_user((void *) maddr + phdr->p_filesz, excess); > - if (ret) > - return ret; > + if (clear_user((void *) maddr + phdr->p_filesz, excess)) > + return -EFAULT; > } > #endif > > -- Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp> -- 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/
Powered by blists - more mailing lists