linux-kernel - Re: [ 00/19] 3.10.1-stable review

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1373713889.17876.135.camel@gandalf.local.home>
Date:	Sat, 13 Jul 2013 07:11:29 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jochen Striepe <jochen@...ot.escape.de>
Cc:	Dave Jones <davej@...hat.com>, Theodore Ts'o <tytso@....edu>,
	Guenter Roeck <linux@...ck-us.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable <stable@...r.kernel.org>
Subject: Re: [ 00/19] 3.10.1-stable review

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 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/