A Flood of Stable Linux Kernels Released

Julie188 writes "Greg Kroah-Hartman has released five new stable Linux kernels, correcting minor errors of their predecessors and including improvements which are unlikely to generate new errors. As so often with kernel versions in the stable series, it remains undisclosed if the new versions contain changes which fix security vulnerabilities, although the number of changes and some of the descriptions of those changes certainly suggest that all the new versions contain security fixes."

Comments

Re:unknown?

[Aboroth]

Since each kernel comes with a complete changelog, it is only "unknown" to people who aren't capable of reading it. It has always been the responsibility of those who build kernels to pay attention to this. I don't recall there ever being a special designation on the front page of kernel.org to designate kernels that fix security vulnerabilities. If you go through a vendor I'm sure they keep up on this or they are incompetent. If you patch your own kernels then you should pay attention to the changelogs. As always.

Yay for sensationalist writing.

Re:unknown?

[Enderandrew]

This has been the policy of the Linux kernel for ages.

They don't go out of their way to hide security fixes, but they don't advertise them either. All bugs are treated as bugs. You can read the lengthy changelog.

Linus doesn't believe in calling special attention to closed bugs, because it also alerts people that there are unpatched security holes in earlier versions. Some shops don't patch Linux boxes regularly.

Re:unknown?

[0racle]

Since Linus decided security holes and bugs are not any different then a bug that causes your screen to refresh a microsecond slower. They list everything as bug fixes and don't differentiate on the potential severity of the bug.

fixes are fully disclosed, stop fud'ing

[bl8n8r]

The disclosures aren't in a pretty clicky-clicky-box but the kernel devs *do* strive to maintain formats which cater to the major users:

for shell ninjas:
    wget www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33 -O - | less

for geezers/people with lawns:
    telnet ftp.kernel.org 21

for the lamer++:
    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33

Re:fixes are fully disclosed, stop fud'ing

[Anonymous Coward]

I'm a programmer by trade but this change log is absolutely useless to me. For example:

Revert the change made to arch/ia64/sn/kernel/setup.c by commit
        204fba4aa303ea4a7bb726a539bf4a5b9e3203d0 as it breaks the build.

        Fixing the build the b94b08081fcecf83fa690d6c5664f6316fe72208 way
        breaks xpc because genksyms then fails to generate an CRC for
        per_cpu____sn_cnodeid_to_nasid because of limitations in the
        generic genksyms code.

What the fuck does that even mean and how does it affect an average user? How am I supposed to know if this is a security problem or not? This resembles a commit log, not a change log.

Re:fixes are fully disclosed, stop fud'ing

[compro01]

If you don't know what that means, you're probably not a member of the 2% or so of users who manually upgrade their kernel and thus probably don't need to worry about it. These updates to your system will be handled by the maintainers of whatever distro you use.

Though to summarize that one, it's undoing a fix (the original issue caused the kernel not to build) to some initial setup code (find the terminal, initialize additional CPU cores, etc.) for the Itamium processor which would cause genksyms (GENerate Kernel SYMbolS, which generates symbol version (checksum of all the typedefs, structs, unions, etc. in the kernel down to their base types) information) not to work properly as it fails to generate the checksum for a particular variable in a struct.

Re:If this were Windows

[The MAZZTer]

Microsoft has since the leak you described moved "bugward compatibility" into something called "shims". They are basically compatibility fixes that only affect specific applications, to ensure newly written apps won't run into the compatibility hacks. More info.

Re:Variety is the spice of life

[mandelbr0t]

Because all the distro's packages were tested against kernel 2.6.27. Integration testing is a badly overlooked phase by many distros. However, I've seen that Debian-based stuff undergoes extensive integration testing, thus making a kernel version upgrade a huge testing process. Fixing the bug in the kernel version used by the distro saves a lot of testing time, and is much less likely to break distro-specific applications.

Revision ids in the GIT repository...

[mengel]

Those big long hex numbers are revision id's in the GIT version control system used for the kernel. Perusing any instance of said repository (such as the one here will let you look at that commit, what files changed, what log messages were included, who made it, etc.

Re:Revision ids in the GIT repository...

[Anonymous Coward]

Fair enough but that still doesn't give me any idea of what was actually fixed from an end user perspective. I still don't know what configurations the fix might affect. I still don't know if it's a security issue.

Take this article from Microsoft for example:
http://www.microsoft.com/technet/security/bulletin/ms09-032.mspx
It says in plain English which versions of the software will need the patch and how the flaw might be exploited. It even gives an estimate of how critical the vulnerability could be.

I think this is the kind of thing that the submitter is looking for when he says "it remains undisclosed if the new versions contain changes which fix security vulnerabilities".

Re:Revision ids in the GIT repository...

[Anonymous Coward]

If you want information digested in that way, maybe you should use get kernel updates from a Linux distribution, not from the kernel developers.

Re:Who cares?

[Flossymike]

Well I like Monkey Island :-)

Kernelnewbies

[JonJ]

Always has a nice human readable summary of the changes.

Re:Variety is the spice of life

[MikeyO]

This might have been a more reasonable thing to do when we had the "even numbered" series (2.0, 2.2, 2.4) for stable kernels and "odd numbered" (2.1, 2.3, 2.5) kernels for new features. But now 2.6 is where both stable kernels and new development is released from, So things you might have been relying on could drastically change from one stable release to the next. For example, the entire devfs subsystem was removed completely in kernel 2.6.13. If you had something that depended on the existence of devfs, you could not upgrade to 2.6.13 or later until you got rid of your dependance on devfs.

Re:If this were Windows

[shutdown -p now]

This is a pretty sharp contrast with Linux programming where such stunts as using the OS in unconventional was is at the very least severely frowned upon

I can assure you that using undocumented APIs, or relying on undocumented behavior and effects of public APIs, is very much frowned on by Microsoft developers as well. You only need to read Raymond Chen's blog to find that out...

Re:unknown?

[kbielefe]

This is exactly what distributions do. Only people who really know what they're doing get their kernels directly from kernel.org. Even if you know what you're doing, it's still more convenient for most people to just get security updates from their distro.

A more apt analogy is a car manufacturer putting out a list of recalls, and your dealership giving you a personal call when the most serious recalls are needed.