Greg Kroah-Hartman has announced the
release of the 2.6.32.6 kernel. There are many fixes, throughout the tree,
and, as usual, 2.6.32 users are "very strongly encouraged to
upgrade".
(Log in to post comments)
Stable kernel 2.6.32.6
Posted Jan 25, 2010 20:05 UTC (Mon) by jimparis (subscriber, #38647)
[Link]
I wish the descriptions were more useful than the generic "users are very strongly encouraged to upgrade". Is that strongly as in "it's worth an hour of downtime for five virtual machines due to a security hole", or strongly as in "oh noes my INTOVA Pixtreme camera doesn't work anymore"?
Stable kernel 2.6.32.6
Posted Jan 25, 2010 22:13 UTC (Mon) by clugstj (subscriber, #4020)
[Link]
Then read the actual announcement and decide for yourself!
Stable kernel 2.6.32.6
Posted Jan 25, 2010 22:31 UTC (Mon) by jimparis (subscriber, #38647)
[Link]
I do -- but all the announcements ever say is "All users of the 2.6.32 kernel series are very strongly encouraged to upgrade." Same thing, every time. That's my point. Sure, it's followed by the kernel shortlog. Some of them I can figure out (as I alluded to in my original post; things like "USB: fix usbstorage for 2770:915d delivers no FAT" clearly only apply to specific hardware, in this case a camera). But plenty of others, like "fix race in tty_fasync", "remove BUG_ON due to racy counting", "use after free"... not always so clear.
Stable kernel 2.6.32.6
Posted Jan 25, 2010 22:50 UTC (Mon) by Oddscurity (subscriber, #46851)
[Link]
Race conditions and uses after free tend to be potential security
sensitive, or at the very least can cause denial of service.
I see what you're saying in that a kernel end-user doesn't
necessarily know what impact certain fixes have and what the priority
in their specific case would be.
Too bad there's no tool similar to 'make localmodconfig' that would
parse these short logs and tell you what fixes apply to things you're
actually using.
Stable kernel 2.6.32.6
Posted Jan 26, 2010 1:15 UTC (Tue) by smadu2 (subscriber, #54943)
[Link]
What your parent might be implying is that you have to have sufficient
(rather indepth) knowledge of all subsystems of the kernel and read through
commits/associated patches and figure out yourself if its a security hole or
not or rely on your distro to provide hints. If you are administrator (like
100% of people who are responsible for deploying Linux) then tough luck !
Suck up the downtime!.
Stable kernel 2.6.32.6
Posted Jan 26, 2010 7:38 UTC (Tue) by viiru (subscriber, #53129)
[Link]
> What your parent might be implying is that you have to have sufficient
> (rather indepth) knowledge of all subsystems of the kernel and read through
> commits/associated patches and figure out yourself if its a security hole
> or not or rely on your distro to provide hints.
The kernel developers themselves often get this wrong, usually by missing the security implications of a bug. This is at least part of the reason for not providing the "this version has security fixes, this does not" type of info you are asking for. Most kernel bugs are potential security bugs to a sufficiently motivated attacker.
Stable kernel 2.6.32.6
Posted Jan 27, 2010 6:06 UTC (Wed) by bojan (subscriber, #14302)
[Link]
If kernel developers don't know this, then how on earth are regular folks supposed to know? (rhetorical)
Just excuses, IMHO. If something is _known_ to have security implications, then it should be called a security fix. The rest of the stuff, of course, _may_ have security implications too, but they are not yet known.
Every other software on the planet uses this convention, but Linux developers decided to obfuscate. Ah, well...
Stable kernel 2.6.32.6
Posted Jan 26, 2010 18:52 UTC (Tue) by clugstj (subscriber, #4020)
[Link]
Each person has their own idea of how important a particular fix is. I don't think it is reasonable to expect the Linux kernel developers to know what your particular criteria is for upgrading.
Even once you have reasonable criteria for what kind of bugs would cause you to do an upgrade, it is still a lot of work to determine if any particular bug qualifies. The kernel developers don't necessarily think like a black-hat, so they are not the best possible people to make this determination.
If you can't tell from the patch descriptions and contents if the bug is important to you, then maybe you should either run a distribution kernel or pay someone to make the determination.
Stable kernel 2.6.32.6
Posted Jan 26, 2010 19:45 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
the best thing that you can do is to look and see if the features that are being fixed are in the kernel that you deploy.
if you are using a vendor kernel, there are other things in there and you need to get the update from the vendor anyway.
if you are compiling your own, compile in as little as possible, and then if there are updates to the things that you have compiled in, you need to update.
Stable kernel 2.6.32.6
Posted Jan 26, 2010 10:44 UTC (Tue) by epa (subscriber, #39769)
[Link]
I wonder if ksplice will ever become mainstream enough that most people can upgrade without more than a few seconds of downtime?
Stable kernel 2.6.32.6
Posted Jan 26, 2010 14:27 UTC (Tue) by hmh (subscriber, #3838)
[Link]
You have crashers and data corruption in the shortlog, and at least two that are likely to be potential security problems of the privilege escalation sort.
The reason why almost every stable kernel published lately has a "strongly encouraged to upgrade" level is that fixes to very nasty stuff have been present in almost every stable release lately.
Which is sort of expected: people are still VERY bad at keeping a proper feed of bug fixes to -stable, so most of the stuff that ends up sent there are fixes for nasty stuff, which pretty much guarantees that a stable release where only minor problems are being fixed will be rare.
If you want less churn, you should use 2.6.27.y for a while yet.
Stable kernel 2.6.32.6
Posted Jan 26, 2010 15:20 UTC (Tue) by vonbrand (subscriber, #4458)
[Link]
Stable kernel updates (by definition) only include fixes for potentially serious problems. Is it worth several hours of downtime (shut down until a replacement kernel has been compiled, I presume)? I don't think so. OTOH, if the machines are so important that immediate shutdown is warranted on a mild threat warning, I'd invest in other protection and beefier build infrastructure...