I get a lot of people asking me why, when it comes to my own servers, Annvix, and my own personal recommendations to people who ask what kernel to use, I whole-heartedly do not recommend the 2.6 kernel and instead advocate the stability and greater security of the 2.4 kernel. Well, for kicks I downloaded a CSV file of the entire CVE database from MITRE’s CVE downloads page and did some poking around to determine some metrics. Note that the CVE database starts in 1999, so it should cover everything from the 2.4 kernel’s first release until today, and, of course, the 2.6 kernel to boot.

To determine the results, I had to cull some of the non-linux data, so I grepped for “linux” first, then took that output file and grepped for kernel to get my final dataset to work with, and is a lot more manageable (363k vs. the 12.7MB download file).

The problem here also is with how the CVE names are described. For instance, it’s not easy to determine, by looking at a CVE entry if something that says “SCTP in Linux kernel before 2.6.16.17 bla bla evil thing” means it affects all 2.6 kernels, or if it also affects 2.4 kernels. I’m leaning towards the former because other entries say things like “The foo function in Linux 2.4.x and 2.6.x before 2.6.16 bla bla naughty stuff”, which clearly indicates both 2.6 and 2.4 are involved. I also removed all the external references from each line in the CSV so the line simply contains the CVE name, whether it’s an entry or a candidate, and the MITRE description.

So, while these results cannot be considered scientific or probably even closely accurate, let’s look at a few things. The first is the first and last CVE names for a given kernel where their version shows up in the description:

2.2 - CVE-1999-0804 to CVE-2005-1263 (22 total) 2.4 - CVE-2001-0907 to CVE-2006-2071 (59 total) 2.6 - CVE-2003-0986 to CVE-2006-2629 (132 total)

The above was obtained using:

egrep "kernel.*2\.6\." linux-cve.csv|wc -l

which might not be 100% accurate given some representations are given as simply “kernel 2.6”, etc so doing it again using “kernel.*2.6” and so forth gives the folloowing:

2.2 - 26 total 2.4 - 77 total 2.6 - 154 total

So the variance isn’t actually too bad. For a complete reference, there were 308 total CVE entries from CVE-1999-0216 to CVE-2006-2629 in the file. Now, if you consider the fact that no mater which number you look at, the number of 2.6-related vulnerabilities is at least twice as high as that of 2.4, that 2.4 hasn’t yet been retired so has been “active” for 5 years whereas the 2.6 kernel has only been for 3 years, well, you kinda get the idea of why I don’t look too fondly on the 2.6 kernel.

Sure, it has some kick-ass features (I, for one, would love to play around with AppArmor), but it also has some severe drawbacks and because I get mailings multiple times a day from MITRE with new CVE name assignments, and I see so many more 2.6-related stuff than 2.4-related stuff… well, I’ve got a theory and some people will dislike it, but whatever.

Until kernel development branches to 2.7 and the 2.6 kernel is left the hell alone, it will continue to suck, continue to have security issues introduced everytime you turn around (folks, most of these vulnerabilities are being introduced during the 2.6 lifetime! This isn’t old stuff!), you find more security holes. Frankly, I feel bad for the Mandriva kernel maintainer (sorry Luiz, you have a shit job having to deal with this). I feel for all vendors who have to support the 2.6 kernel. I’m quite happy that Annvix is using the 2.4 kernel and, although we plan to include 2.6 in some fashion for the next release, I promise you that the 2.6 kernel will never be the default until they stop dicking around with it and move on to 2.7 to change APIs and goof off with neat new things, and leave the 2.6 series to stabilize. This crap about vendors picking and maintaining a 2.6 “sub-branch”(?) like 2.6.15 or 2.6.16 and going from there is crap. If you’re going to do that, you might as well move on and branch to 2.7 and leave 2.6 in 100% maintenance mode, like your happy, friendly, stable, and much less insecure 2.4 friend is.

This is why I dislike the 2.6 kernel so much. I think the whole change of development style from 2.4 to 2.6 completely butchered the stability of the kernel, and the security. Yup, I will probably get flamed like mad for this, but the stats don’t lie (perhaps just the interrpetation of them, but I can’t see how you can interpret that in a “nice” light).

FWIW, I would much rather have used MITRE’s search tool on their website, but the search results were coming up with 20-something results when searching for 2.4 or 2.6 and I know that’s wrong… our last few Mandriva updates have had 20 CVE names in a single advisory so I know that’s not right.

Anyways, there… now if someone asks me (again) why I don’t like the 2.6 kernel, I can point them here. And if someone feels like going through the CVE names with a little more accuracy in mind (I’m happy with generalizations) please feel free and let me know the specifics. It’s almost 1:00am here and I just don’t have the time, desire, or patience to be anal… err… completely 100% accurate.

Share on: TwitterLinkedIn


Published

Category

Linux

Stay in touch