On Sat, 2013-07-13 at 02:47 +0200, Jochen Striepe wrote: > Hello, > > On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote: > > I would suspect that machines that allow unprivileged users would be > > running distro kernels, and not the latest release from Linus, and thus > > even a bug that "can allow an unprivileged user to crash the kernel" may > > still be able to sit around for a month before being submitted. > > > > This wouldn't be the case if the bug was in older kernels that are being > > used. > > On the one hand, you seem to want users with any kind of production > systems to use distro kernels. On the other hand, developers want > a broad testing base, with vanilla kernels (or better, rc) as early > as possible. You cannot get both at the same time, some kinds of bugs > just appear on production systems. > > Users expect vanilla .0 releases usable as production systems, to > be updated (meaning, no new features, just stabilizing) with the > corresponding -stable series. This really is a case by case basis. An unprivileged user exploit requires a box that lets other users than the owner of the box to log in. Most users of .0 releases do not do this. But this isn't the point anyway. The point I was making is not to let the fix be worse than the bug it fixes. What happens if the fix to an unprivileged user exploit inadvertently opens an off by one bug that can be exploited by external users? It comes down to each bug itself. If the fix is trivial and fixes a critical bug, it should be pushed rather quickly to mainline. But if the fix requires a redesign of some code, it would require more time. Luckily, most security bugs are quick fixes, and don't need a redesign of the code. -- Steve -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html