# KERNEL SECURITY BUG: NULL pointer dereference in proto_ops

## jonathanross

Hello,

I see this is noted on the packages site for Gentoo Sources http://packages.gentoo.org/package/sys-kernel/gentoo-sources for the NULL pointer dereference due to incorrect proto_ops initializations bug but it's been there since yesterday.

```
*gentoo-sources-2.6.30-r5 (14 Aug 2009)

14 Aug 2009; Mike Pagano (mpagano)

+gentoo-sources-2.6.30-r5.ebuild:

Fix for (CVE-2009-2692), Kernel: NULL pointer dereference due to incorrect

proto_ops initializations. Fix for Linux Kernel clock_nanosleep() NULL

Pointer Dereference, SA36200. Security hid dereference before null check

fix. New patch for fbcondecor.
```

Does anyone have a known time for a release of the r5 sources or should I manually patch my boxes ?

One post said SPARC wasn't affected and others said they were. Any input ?

Thanks,

JR   :Smile: 

----------

## pappy_mcfae

It's in portage as of the time of this post.

Blessed be!

Pappy

----------

## jonathanross

Hi Pappy !

Thanks for responding.

Which sync Server are you using ? I've tried rsync.us. rsync.namerica. rsync.europe. etc.

I still see: 

```
sys-kernel/gentoo-sources-2.6.30-r4
```

Mucho thanks,

JR   :Confused: 

----------

## Akkara

It is there.  It is just marked ~.  So you need to keyword it if you are running stable.

----------

## jonathanross

Ahh, okay. Sorry for being a noob.

If it's unstable should I avoid it for production boxes ?

I thought it was just a small change to fix this bug so I'm not sure why it's marked unstable.

EDIT: Just found this doc: http://learn.clemsonlinux.org/wiki/Gentoo:Masked_ebuilds

Many thanks !

JR

----------

## Akkara

I'm not sure why it is unstable.  Maybe they want to test it a day or two just to be sure.  Could be a small thing, such as making sure the patch has been copied over to the mirrors, trivial stuff that most likely is correct, but in the rare case that it isn't, doesn't cause screams of surprise.  (Total guesses, there.)

Since this is a pretty important one, in case you (or someone else reading this thread) isn't aware, it is possible to keyword a specific instance of a package.  So you can use that one without later on having it upgrade every time another unstable kernel is released: *tail -1 /etc/portage/package.keywords wrote:*   

> =sys-kernel/gentoo-sources-2.6.30-r5

 

----------

## jonathanross

Thanks very much, Akkara !

You have been most helpful.

 :Very Happy: 

----------

## jak137

What about 2.6.27 series? Do I have to upgrade to 2.6.30 or are there available (or are going to be) patched sources for earlier versions?

----------

## cach0rr0

 *jak137 wrote:*   

> What about 2.6.27 series? Do I have to upgrade to 2.6.30 or are there available (or are going to be) patched sources for earlier versions?

 

As I understand it 2.6.27 isn't affected

Could be wrong there, and I'm sure someone else will chime in, but I've read somewhere that this doesn't affect versions other than 2.6.30-r1 thru -r4 OR a very early patched Red Hat kernel

----------

## Bircoph

 *cach0rr0 wrote:*   

> 
> 
> As I understand it 2.6.27 isn't affected
> 
> 

 

All series till 2.6.30.4 inclusively are affected.

BTW, it is very easy to workaround this bug without kernel update: just disallow mmap to zero page:

```

echo 4096 > /proc/sys/vm/mmap_min_addr

echo "vm.mmap_min_addr = 4096" > /etc/sysctl.conf

```

----------

## jonathanross

That could save the day but the release from the guys that discovered it said that it "may" be a workaround if I remember correctly.

 :Crying or Very sad: 

----------

## monsm

Good thing I saw this thread, was about to update the kernel.  Thanks guys.

I was under the impression that this Null Pointer problem got discovered and fixed in the release candidate stage.  Am I wrong or is this a second similar bug?  I think I saw something elsewhere about it.

Mons

----------

## jonathanross

Here's as 'official' as I can find:

http://www.cr0.org/misc/CVE-2009-2692.txt

 *Quote:*   

> -------------------
> 
> Mitigation
> 
> -----------------------
> ...

 

http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html

JR   :Smile: 

----------

## cach0rr0

ah yes, now i remember where I got that info

looking at the exploit code comments:

```

/* super fun 2.6.30+/RHEL5 2.6.18 local kernel exploit in /dev/net/tun

   A vulnerability which, when viewed at the source level, is unexploitable!

   But which, thanks to gcc optimizations, becomes exploitable :)

   Also, bypass of mmap_min_addr via SELinux vulnerability!

   (where having SELinux enabled actually increases your risk against a

    large class of kernel vulnerabilities)

```

```

The commit that introduced the vulnerability (Feb 6th):

    http://mirror.celinuxforum.org/gitstat/commit-detail.php?commit=33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554

    Though it was committed before the release of the 2.6.29 kernel, it 

    did not (thankfully) make it into the 2.6.29 kernel.  It first 

    appeared in 2.6.30.

```

----------

## mikegpitt

It looks like it is still marked ~arch as of 8/18.  I'm sure it's just related to some extra testing.  Although the vuln is critical, it is also local, so I am personally waiting until the devs mark it stable in case there is other breakage in -r5.

----------

## cach0rr0

local indeed, though the thought of a remote file inclusion vuln in another app allowing this to be run even as the apache user == your box is rooted, you're fairly screwed. 

I guess not really an issue if the rest of your remotely-exposed applications/daemons are tightened down as they should be

----------

## jonathanross

I opted to go for the unstable kernel on a few production boxes in the end. With one left unpatched which needs a maintenance window.

Both SPARC64 and x86 boxes seem to be behaving well a few days in.

Although there's only a few daemons listening and everything is patched you never when that zero day bug might appear.

JR   :Smile: 

----------

## cach0rr0

So the one item I'm not completely clear on - whether or not this affects hardened sources with the usual round of PaX (and well, grsec, but that's irrelevant here) options selected

I'm running 2.6.28-r9 with the 'hardened server' profile selected; but say I was on a branch that included the vulnerable code, would the hardened patches nullify the risk?

----------

## jonathanross

I'm not qualified to answer I'm afraid   :Sad: 

Some of the chatter online has smirked at the extra kernel security actually being hit worse than standard builds and this is all I've seen 'officially' from my post above:

 *Quote:*   

> However, administrators should be aware that LSM based mandatory access control systems, such
> 
> as SELinux, may alter this functionality. 

 

JR   :Smile: 

----------

## mikegpitt

Actually in retrospect, I think I'm going to unmask -r5 and update today (since I have some time).  I think it is very likely that the devs will be marking this one stable soon.  If any issues to arise out of the version bump I think they would be reflected in a -r6 since -r5 is already in portage.  Basically, if you unmask today and see that it goes stable in another day or two it shouldn't cause any negative issues.

----------

## jonathanross

That was my theory too. 

That said, it was committed on Friday to Portage (which was a great response to the bug being announced) so it's already a few days but as I said we've still to see any instability issues on SPARC64 or x86 (formerly running 2.6.29 kernels).

I would hope it's just some testing that needs to be completed too. I can do the maintenance window box's upgrade once it's stable.

JR   :Smile: 

----------

## krinn

what a mess!

I prefer own a server with an unstable secure kernel, than a stable hackable one !

i could still reboot an unstable server for a min downtimes, what will we do if our root password is change, config... deleted.... BIG downtime !

----------

## jonathanross

I'm with you on that !!

----------

## pappy_mcfae

According to one of the above posted articles, this issue does have a fix, and has been summarily fixed in all versions (.27 and .30) released since that issue was discovered. So, once again, it seems it's time to do a bit of fixing. Since I run .29 on this machine, I guess that means me. hehehe

Blessed be!

Pappy

----------

## krinn

but i read from the guy that found the hole that 32bits grsec+pax shoudn't be affect. (don't ask me why)

 *Quote:*   

> Exploits the vulnerability in all Linux kernels since 2001. Exploit works on all kernels since 2001. Disables SELinux, AppArmor, LSM -- you know the drill.

 

----------

## cach0rr0

 *jonathanross wrote:*   

> I'm not qualified to answer I'm afraid  
> 
> Some of the chatter online has smirked at the extra kernel security actually being hit worse than standard builds and this is all I've seen 'officially' from my post above:
> 
>  *Quote:*   However, administrators should be aware that LSM based mandatory access control systems, such
> ...

 

That was specific to SELinux as I understand it

Here is the commentary from exploit.c, that's been passed around along with the disclosure - http://whitehathouston.com/kernsploit.txt

Obviously I'm not going to include the whole thing (though anyone with google can find the code)

That's been my main source of info on this one.

----------

## jonathanross

Thanks, that's of interest.

One final point ... upgrading to 2.6.30-gentoo-r5 hasn't been that much fun   :Sad: 

Hopefully, this might help someone:

https://forums.gentoo.org/viewtopic-p-5937289.html#5937289

JR   :Smile: 

----------

