Linux NULL pointer dereference due to incorrect proto_ops initializations
 

Complete Article (Please note that Linus Torvalds commited a patch for this today).

BTW, thanks to Slashdot for covering this.

Is this a problem that your distro would issue an updated package for? or do you need to fix the problem yourself?

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.

Thanks unSpawn.

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

https://bugzilla.redhat.com/show_bug.cgi?id=516949#c10

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)

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.

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

Yeah that looks ok, thanks for the link :)


slackware.

there are no packages available yet. I think I'll wait untill monday, and then have a go at it myself.

Thanks :)

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?

PF_APPLETALK, PF_IPX, PF_IRDA, PF_X25, PF_AX25, PF_BLUETOOTH, PF_IUCV, IPPROTO_SCTP/PF_INET6, PF_PPPOX, PF_ISDN

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:

grsecurity-2.1.14-2.6.29.6-200908140946.patch

2.6.27.30 and 2.6.30.5 official kernels have been released and include the fix for this issue.
Time to get compiling...

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.

@bloodsugar, Yes, that's not unusual. Especially when only changing the minor version number.

I didn't see any new options when going to 27.30 either.

I see, thanks Gaz,

btw, whats the 2.6.27.30 kernel?

Interestingly enough, they did release one this time.