linux-kernel - Re: [BUG] binfmt_elf: get_user() called in vma_dump_size() after set_fs(KERNEL

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: <20090207015553.3EE46FC3AD@magilla.sf.frob.com>
Date:	Fri,  6 Feb 2009 17:55:53 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Gerald Schaefer <gerald.schaefer@...ibm.com>,
	linux-kernel@...r.kernel.org, schwidefsky@...ibm.com,
	heiko.carstens@...ibm.com
Subject: Re: [BUG] binfmt_elf: get_user() called in vma_dump_size() after
 set_fs(KERNEL_DS)

> Yes, I suspect just surrounding the load with set_fs(USER_DS) and then 
> set_fs(KERNEL_DS) to put it back is likely the right thing to do.

Agreed.

> The address is "safe" in that it does come from the vma, but we obviously 
> do play games with things like the call gate mappings etc. 

gate_vma has VM_ALWAYSDUMP so it never sees this whole path anyway.
I doubt there is any actual case.  But, point taken.

> Should we also perhaps do this only if the vma is marked readable and
> executable? That way we could avoid taking unnecessary faults there.
> 
> Probably doesn't really matter. 

I'm sure it doesn't really matter.  But, just to say it all: Requiring
VM_EXEC would actually exclude some valid cases.  Even requiring VM_READ is
less than perfect as far as pedantic semantics go--but there is no reason
not to check it since its lack rules out get_user() actually working
anyway.  I already chose that trade-off since get_user() here is so much
cheaper than get_user_pages().  The core dump from a stray
"mprotect(0,1UL<<32,PROT_NONE)" (i.e. presumably actually one with some
arithmetic error) would be useful if we made the check work without
VM_READ, but oh well.

Thanks,
Roland
--
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/