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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 28 Dec 2012 19:21:52 +0000 From: Al Viro <viro@...IV.linux.org.uk> To: Vasily Kulikov <segoon@...nwall.com> Cc: kernel-hardening@...ts.openwall.com, Containers <containers@...ts.linux-foundation.org>, "Serge E. Hallyn" <serge.hallyn@...ntu.com>, linux-kernel@...r.kernel.org, "Eric W. Biederman" <ebiederm@...ssion.com> Subject: Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts On Fri, Dec 28, 2012 at 11:04:35PM +0400, Vasily Kulikov wrote: > > I'm sorry, but this is not a solution. Kernel is not x86-only; there are > > architectures with far bigger minimal stack frame size. E.g. on sparc64 > > every fucking stack frame is at least 176 bytes. So your 100 calls deep > > call chain will happily overflow the damn stack all by itself - kernel > > stack on sparc64 is 16Kb total, including struct thread_info living there. > > Understood. How to properly fix it then? Looks like there are quite > many kernel structures which may reference other structures which > indirectly reference each other via kref, IOW it is not user_ns specific > issue. With unprivileged user_ns the way it should be freed must be > somehow changed. There are many damn good reasons why kref should *not* be used without thinking. It's been oversold as easy solution to all refcounting problems; it isn't one. Don't use it here. -- 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