On Wed, Oct 10, 2012 at 01:54:08PM -0700, Andrew Morton wrote: > 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?
I believe it'll apply on stable even in current form. As Eric mentioned CAP_SYS_ADMIN is required (so it's not that urgent i think). -- 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/
