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: <1373730866.17876.139.camel@gandalf.local.home>
Date:	Sat, 13 Jul 2013 11:54:26 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Dave Jones <davej@...hat.com>
Cc:	Jochen Striepe <jochen@...ot.escape.de>,
	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 11:10 -0400, Dave Jones wrote:
> On Sat, Jul 13, 2013 at 07:11:29AM -0400, Steven Rostedt wrote:
> 
>  > > 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.
> 
> local exploits aren't just a problem for multi-user machines.
> An attacker who can own your firefox process, can now potentially
> escalate to root.  (Ok, most exploits are just crashing the box,
> but how many times have we been proven wrong in the past when we
> thought something was just a DoS, and someone smarter has found
> a way to turn it into a root-hole?)

Of course I don't want to lower the importance of such a fix. But making
sure the fix works and not rushed out is important too. It really is a
case by case basis. Some bugs should get out to mainline and stable
quickly, but a lot of them should also be verified to work before
rushing to get them out the door. And verification does take a bit of
time. The last thing we want a fix to do is to create a bug that could
potentially be worse than the one being fixed.

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