Andrew Morton <[email protected]> writes: > On Thu, 11 Oct 2012 00:42:56 +0400 > Cyrill Gorcunov <[email protected]> wrote: > >> The free_pid_ns function done in recursion fashion: >> >> free_pid_ns(parent) >> put_pid_ns(parent) >> kref_put(&ns->kref, free_pid_ns); >> free_pid_ns >> >> thus if there was a huge nesting of namespaces the userspace >> may trigger avalanche calling of free_pid_ns leading to >> kernel stack exhausting and a panic eventually. >> >> This patch turns the recursion into iterative loop. >> >> v5 (from oleg@): >> - Drop @ret variable >> - Make put_pid_ns non-inline since it grows in size, >> in turn make free_pid_ns static > > OK, let's try that. I'll sit on this until -rc2 to give it a bit of > time to cook. > > A -stable backport might be needed. What capabilities does userspace > need to be able to trigger the kernel stack overflow?
CAP_SYS_ADMIN is required to create a new pid namespace today. With a little luck the user namespace bits that allow unprivelged creation of pid namespaces will be ready for 3.8. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
