Linux NULL pointer dereference due to incorrect proto_ops initializations
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Linux NULL pointer dereference due to incorrect proto_ops initializations
Quote:
Tavis Ormandy and [Julien Tinnes] have recently found and investigated a Linux kernel vulnerability. It affects all 2.4 and 2.6 kernels since 2001 on all architectures. [They] believe this is the public vulnerability affecting the greatest number of kernel versions.
The issue lies in how Linux deals with unavailable operations for some protocols. sock_sendpage and others don't check for NULL pointers before dereferencing operations in the ops structure. Instead the kernel relies on correct initialization of those proto_ops structures with stubs (such as sock_no_sendpage) instead of NULL pointers.
Distributions can backport fixes and release an updated kernel package but you can also compile the vanilla kernel.org kernel yourself if you wouldn't want to wait.
I have compiled a vanilla kernel from kernel.org in the past, however, I have not applied a fix like this before, Im guessing its a case of copying the file to the correct directory in the kernel source and compiling?
Is there a chance I could screw this up? would I be better off waiting for kernel.org to update their 2.6 kernel and then compiling that?
Last edited by bloodsugar; 08-14-2009 at 08:32 AM.
I have compiled a vanilla kernel from kernel.org in the past, however, I have not applied a fix like this before, Im guessing its a case of copying the file to the correct directory in the kernel source and compiling?
Is there a chance I could screw this up? would I be better off waiting for kernel.org to update their 2.6 kernel and then compiling that?
kernel.org has applied the fix to the tree yesterday but not all vendors have a fix yet
here is the recommended red hat fix for the time being. It may work on other distros since its all modprobe changes but not 100% sure. (i dont see why it wont tho)
I have compiled a vanilla kernel from kernel.org in the past, however, I have not applied a fix like this before, Im guessing its a case of copying the file to the correct directory in the kernel source and compiling?
Kind of. You basically download the patch, then run it through the patch program, which will apply the necessary changes to the file(s) in your source code. You can read something like this to get a better understanding of the patching process. It's actually really simple once you get the hang of it.
Quote:
Is there a chance I could screw this up? would I be better off waiting for kernel.org to update their 2.6 kernel and then compiling that?
Of course there's a chance you could screw up. BTW, what distro do you use? I ask because your distro will likely be releasing updated kernel packages soon (check with their bug tracker for relevant discussion). For what it's worth, Debian released a patched kernel package today.
Code:
win32sux@stingray:~$ uname -a
Linux stingray 2.6.26-2-486 #1 Fri Aug 14 01:02:21 UTC 2009 i686 GNU/Linux
So it looks like you've got at least three choices: wait for your distro to release an updated kernel package; wait for upstream to release a new stable source tarball; or download the current upstream stable source tarball and patch it on your own. The urgency with which you need to fix this vulnerability should probably be the determining factor.
there are no packages available yet. I think I'll wait untill monday, and then have a go at it myself.
Slackware doesn't always release new kernel packages for vulnerabilities like this one. The kernel in Slackware 12.2 is still 2.6.27.7 despite there being many local vulnerabilities fixed between that and the latest 2.6.27.29. I'm not entirely sure what Pat's criteria is for deciding whether to release an updated kernel package or not.
On the plus side, as Slackware doesn't mess with the kernel, it's relatively straight forward to build your own from the upstream sources, which is what I do.
Currently I'm running 2.6.29.6-grsec(all grsec and pax options enabled) but what I want to know is, where do I find the following so I can disable them like in the blog?
Currently I'm running 2.6.29.6-grsec(all grsec and pax options enabled) but what I want to know is, where do I find the following so I can disable them like in the blog?
You could do kernel module blacklisting (such as suggested by Red Hat), but if you're using the latest grsecurity patch for version 2.6.29.6 you're already covered with a proper fix, so this kind of mitigation wouldn't be necessary.
At the time of this post the latest grsecurity patch for version 2.6.29.6 was:
Is it the case that when upgrading a kernel from say, my current kernel 2.6.30.2, to the new 2.6.30.5, sometimes there wont be any new kernel options when you do 'make oldconfig'?
I do the 'make oldconfig' step and it tells me 'configuration written to .config', and exits.
Slackware doesn't always release new kernel packages for vulnerabilities like this one. The kernel in Slackware 12.2 is still 2.6.27.7 despite there being many local vulnerabilities fixed between that and the latest 2.6.27.29. I'm not entirely sure what Pat's criteria is for deciding whether to release an updated kernel package or not.
On the plus side, as Slackware doesn't mess with the kernel, it's relatively straight forward to build your own from the upstream sources, which is what I do.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.