# Root exploit patched in recent kernels.  Which are safe?

## BitJam

This link is from Slashdot.  They say: *Quote:*   

> The problem has been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel.

 

I don't know how to translate those version numbers into versioning used here such as: 

```
gentoo-sources-2.6.32-r2
```

Can someone tell me which Gentoo kernel(s) have been patched to fix this root exploit?

----------

## Letharion

If you take a look at the Changelog in /usr/portage/sys-kernel/gentoo-sources you can see that 2.6.32 has not been updated since 04 Aug 2010.

Thus it is not safe.

However, you will also find that on 14 Aug 2010, gentoo-sources-2.6.34-r5 was commited, and according to the commit comment, this corresponds to 2.6.34.4, which is a safe version, according to the linked article.

There was also a safe 2.6.35 version, but it has been removed due to the new patches causing breakage. https://bugzilla.kernel.org/show_bug.cgi?id=16588

It seems like that problem exists also in 2.6.34.4 though, so I'm under the impression that for the moment there is not a both stable and patched 2.6 kernel to use.

----------

## BitJam

Thanks for the fast and informative response.  I read the entire thread of the bug report you linked to.  It looks like the bug might not have been related (or entirely related) to the patch the fixes that root exploit.  Therefore I am going to try to configure and use gentoo-sources--2.6.34-r5 ASAP.  I'll report success or failure here.

----------

## Letharion

yw

I didn't read the thread in any detail at all, so you're probably right.

Would be interesting to hear if it works. I'm already on 35 though for other reasons, so I'll give it a day or two before I bother to much with it.

The attack does still rely on a malicious user or a compromised GUI app after all, so the danger doesn't feel that immediate to me.

----------

## BitJam

I was able to upgrade from gentoo-sources-2.6.32-r2 to gentoo-sources-2.6.34-r5 with "make oldconfig".  The only problem (so far) was with lirc.  I had to use the ~ version of lirc which also required that I use LIRC_DEVICES="mceusb" instead of LIRC_DEVICES="mceusb2" in make.conf.  I also had to remove the /dev/lircd symlink manually after failed starts of the lircd service.

----------

## BitJam

 *Letharion wrote:*   

> The attack does still rely on a malicious user or a compromised GUI app after all, so the danger doesn't feel that immediate to me.

 

You don't use flash?

----------

## Letharion

 *BitJam wrote:*   

>  *Letharion wrote:*   The attack does still rely on a malicious user or a compromised GUI app after all, so the danger doesn't feel that immediate to me. 
> 
> You don't use flash?

 

Good point  :Wink: 

I do, but for reasons just like this, I actually have lightspark installed, instead of adobe-flash.

I recently installed adobe-flash because I needed to verify a flash-creation of my own worked as intended (and I do hope I can trust those  :Wink:  ), but otherwise I don't have it installed.

----------

## ChrisJumper

Oh i care about this too, yet i think that 2.6.34-r5 is still effected.

Check out the Commend on kernel.org

Seems like this is easy to patch the Lines itself and recompile the kernel.

Here its done.

----------

## BitJam

The patch you linked to has been applied to /usr/src/linux-2.6.34-gentoo-r5/mm/memory.c starting on line 2753.  So ISTM the bug was fixed in that version of gentoo-sources just like Letharion said (from viewing the Changelog).

----------

## ChrisJumper

Thats right.

I missed the Kernel-Version and checked it in the source (but wrong directory), linux-2.6.34-gentoo-r5 is fixed but linux-2.6.34-gentoo-r2 and 2.6.35-gentoo-r1 wasn't.

But i want to use a 2.6.32 Kernel here before i upgrade to 2.6.35 so i fixed it manually before i have to wait for an update in portage.

----------

## depontius

I'm in the process now of moving my laptop back from 2.6.35 to 2.6.34-r5 and my desktop up from 2.6.33 to 2.6.34-r5.

My first 2 compilation attempts failed.  At first I thought it was because I was starting with a 2.6.35 config, and something in 2.6.24-r5 didn't like it, so my second attempt started with an old 2.6.34-r1 config.  It still failed.  A little searching on bugs.gentoo.org found this: https://bugs.gentoo.org/show_bug.cgi?id=332949  It references a post on LKML here: http://lkml.org/lkml/2010/8/15/21

So I tweaked arch/x86/kernel/cpu/vmware.c to include linux/jiffies.h and it has made it through the bzImage, still working on modules.

My problem is, what the heck am I doing attempting to compile vmware.c?  I'm building on 2 systems right now, one is an old Pentium-M laptop, and the other is an even older dual-PIII.  Neither has spit for hardware virtualization support, so I haven't activated ANY virtualization stuff in the configuration.  It doesn't seem to me that I should be attempting to build this file.  I went and looked for "vmware" and "hyper" in my /boot/System.map* files.  Usage of "vmware" was essentially the same for all files.  Usage of "hyper" was the same for 2.6.34-r1 and 2.6.34-r5, and 2.6.35 had a lot more entries, understandable enough.

How did I manage to cleanly compile 2.6.34-r1?  I may need to go reinstall that source, and look at vmware.c there.

----------

## BitJam

@ChrisJumper, I noticed problems with lm_sensors and the 2.6.34-r5 kernel.  It wasn't reporting my k8temp temperatures correctly which then screwed up the fan control.  I futzed around with it for a while but found no joy so I went back to 2.6.32-gentoo-r3 after applying the patch you linked to.  I had to apply one part of the patch manually, but that was pretty easy.

----------

## njsg

 *BitJam wrote:*   

> Can someone tell me which Gentoo kernel(s) have been patched to fix this root exploit?

 

The patch was included in some kernel versions. Please note that, at least as of yesterday, there is no stable and patched kernel.

There is a list of patches by -sources package version. Fixed releases wave the 

"Fix page table unmap for stack guard page properly" patch on the list.

If I didn't misread the lists, this means the following gentoo-sources versions have the patch:

 2.6.32-r14

 2.6.34-r6

Mike Pagano wrote also a blogpost on this:

 *mpagano wrote:*   

> 
> 
> I just released gentoo-sources 2.6.32-r14, 2.6.34-r6 and 2.6.35-r2. These all include the patch for the local privilege escalation flaw bug that was recently announced. So, I do recommended all gentoo-sources users upgrade to these latest versions.
> 
> 

 

2.6.35-r2 is not on the list I linked, I guess I must have skipped something.

----------

## Shining Arcanine

 *depontius wrote:*   

> I'm in the process now of moving my laptop back from 2.6.35 to 2.6.34-r5 and my desktop up from 2.6.33 to 2.6.34-r5.
> 
> My first 2 compilation attempts failed.  At first I thought it was because I was starting with a 2.6.35 config, and something in 2.6.24-r5 didn't like it, so my second attempt started with an old 2.6.34-r1 config.  It still failed.  A little searching on bugs.gentoo.org found this: https://bugs.gentoo.org/show_bug.cgi?id=332949  It references a post on LKML here: http://lkml.org/lkml/2010/8/15/21
> 
> So I tweaked arch/x86/kernel/cpu/vmware.c to include linux/jiffies.h and it has made it through the bzImage, still working on modules.
> ...

 

That was fixed in 2.6.35.3. As for your question, if you used genkernel, it probably turned on a great deal of stuff that you do not need. vmware drivers were added to the kernel for better virtualization guest support. One example is the networking section. As far as I know, none of the stuff is to assist in actually running a host. Your kernel was likely compiled with one of these drivers.

 *BitJam wrote:*   

> This link is from Slashdot.  They say: *Quote:*   The problem has been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel. 
> 
> I don't know how to translate those version numbers into versioning used here such as: 
> 
> ```
> ...

 

I was certain that it was addressed in the versions cited, but according to lwn.net, it seems that what they really meant was that they applied the patch to those stable branches in git after they were released, meaning the next versions (e.g. 2.6.35.3) contain the patch. See lwn.net:

http://lwn.net/Articles/401216/rss

----------

## depontius

 *Shining Arcanine wrote:*   

> 
> 
> That was fixed in 2.6.35.3. As for your question, if you used genkernel, it probably turned on a great deal of stuff that you do not need. vmware drivers were added to the kernel for better virtualization guest support. One example is the networking section. As far as I know, none of the stuff is to assist in actually running a host. Your kernel was likely compiled with one of these drivers.

 

I use genkernel, but I manage my own kernel configs, so I know I'm keeping all of the virtualization stuff turned off.  But if I go look in "/usr/src/linux/arch/x86/kernel/cpu/Makefile" I see a few lines like this:

```
obj-y         := intel_cacheinfo.o addon_cpuid_features.o

obj-y         += proc.o capflags.o powerflags.o common.o

obj-y         += vmware.o hypervisor.o sched.o mshyperv.o

obj-$(CONFIG_X86_32)   += bugs.o cmpxchg.o

obj-$(CONFIG_X86_64)   += bugs_64.o

obj-$(CONFIG_CPU_SUP_INTEL)      += intel.o

obj-$(CONFIG_CPU_SUP_AMD)      += amd.o

obj-$(CONFIG_CPU_SUP_CYRIX_32)      += cyrix.o

obj-$(CONFIG_CPU_SUP_CENTAUR)      += centaur.o

obj-$(CONFIG_CPU_SUP_TRANSMETA_32)   += transmeta.o

obj-$(CONFIG_CPU_SUP_UMC_32)      += umc.o
```

So it doesn't appear that there is any way to turn off vmware, hypervisor, mshyperv, etc.  Incidentally, "CENTAUR" doesn't appear in my xconfig menus, and at the moment appears to always be turned on.  I've never had a Centaur processor, never turned it on, and looking in my old configs, can see it going back to January 2009.

 *Shining Arcanine wrote:*   

> 
> 
> I was certain that it was addressed in the versions cited, but according to lwn.net, it seems that what they really meant was that they applied the patch to those stable branches in git after they were released, meaning the next versions (e.g. 2.6.35.3) contain the patch. See lwn.net:
> 
> http://lwn.net/Articles/401216/rss

 

Today, after last night's cron.daily-driven "emerge --sync" I see gentoo-sources has 2.6.35-r2, 2.6.34-r6, and 2.6.32-r14, all with the note, "Patch to fix page table unmap for stack guard page".  I think that's our fix, and today is the day to rebuild gentoo-sources kernels.  My laptop was running 2.6.35 until Friday when I moved it back to 2.6.34-r5, thinking I'd picked up the fix.  I'm rebuilding now to 2.6.35-r2.  My deskside has been running 2.6.33, and Friday I made a non-functional attempt to move to 2.6.34-r5.  The new kernel oopsed, crashed, and bugged all over the place.  I'll make another attempt to get it to 2.6.35-r2, and then may have to drop back to 2.6.32-r14.  This system has been a bit finicky, all along.

----------

## RioFL

Will this exploit patch make its way to Vserver-Sources soon? We use those exclusively.

----------

## upengan78

Yesterday I ran the diagnostics tool from ksplice on gentoo (  linux-2.6.32-gentoo     )

I got this

```

$$$ Backdoor in LSM (1/3): checking…not present.

$$$ Backdoor in timer_list_fops (2/3): not available.

$$$ Backdoor in IDT (3/3): checking…not present.

Your system is free from the backdoors that would be left in memory

```

Then I ran actual exploit,

and it took to me a root sh-3.2#

Again ran diagnostics, 

```
Your in-memory kernel HAS A BACKDOOR that may have been left by the published exploit for CVE-2010-3081.
```

I upgraded kernel to 2.6.35-gentoo-r7 immediately and rebooted.

Now diagnostics tool shows,

```
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.

(see http://www.ksplice.com/uptrack/cve-2010-3081)

$$$ Kernel release: 2.6.35-gentoo-r7

!!! Could not find symbol: per_cpu__current_task

A symbol required by the published exploit for CVE-2010-3081 is not

provided by your kernel.  The exploit would not work on your system.
```

Is there a bug report on gentoo site for this vulnerability? Please let me know. Thanks.

----------

## krinn

 *upengan78 wrote:*   

> 
> 
> ```
> Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
> 
> ...

 

Why, it has just told you the exploit cannot be done on that kernel. It might be the kernel itself that doesn't export the per_cpu_current_task symbol to stop the exploit, or you have remove an option that remove that symbol. One or the other, but result is the same.

here you'll get the info you seek : https://forums.gentoo.org/viewtopic-t-845432.html

----------

## Shining Arcanine

 *depontius wrote:*   

>  *Shining Arcanine wrote:*   
> 
> That was fixed in 2.6.35.3. As for your question, if you used genkernel, it probably turned on a great deal of stuff that you do not need. vmware drivers were added to the kernel for better virtualization guest support. One example is the networking section. As far as I know, none of the stuff is to assist in actually running a host. Your kernel was likely compiled with one of these drivers. 
> 
> I use genkernel, but I manage my own kernel configs, so I know I'm keeping all of the virtualization stuff turned off.  But if I go look in "/usr/src/linux/arch/x86/kernel/cpu/Makefile" I see a few lines like this:
> ...

 

I had bad information. The bug that is the topic of this thread was fixed in 2.6.35.4.

 *upengan78 wrote:*   

> Yesterday I ran the diagnostics tool from ksplice on gentoo (  linux-2.6.32-gentoo     )
> 
> I got this
> 
> ```
> ...

 

That is a different bug. This bug involves the Xorg server and was patched about a month ago. The patch for the bug you are citing is a more recent development.

----------

## Kasumi_Ninja

I'm curious why there isn't security advisory for this exploit.  :Rolling Eyes:  http://www.gentoo.org/security/en/glsa/index.xml

----------

## ThiefMaster

bump. at least patch the hole in the currently stable kernels.

----------

