Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 209460 (CVE-2008-0009) - kernel 2.6.17 - 2.6.24.1 splice: missing user pointer access verification (CVE-2008-{0009,0010,0600})
Summary: kernel 2.6.17 - 2.6.24.1 splice: missing user pointer access verification (CV...
Status: RESOLVED FIXED
Alias: CVE-2008-0009
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Gentoo Kernel Security
URL: http://bugzilla.kernel.org/show_bug.c...
Whiteboard: [linux >= 2.6.17 < 2.6.23.16] [linux ...
Keywords:
: 209530 209533 209602 209992 210156 210263 210451 (view as bug list)
Depends on:
Blocks: 215546
  Show dependency tree
 
Reported: 2008-02-09 21:05 UTC by toogle
Modified: 2018-04-04 17:31 UTC (History)
30 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Linux vmsplice Local Root Exploit (linux_vmsplice.c,6.12 KB, text/plain)
2008-02-09 22:11 UTC, toogle
no flags Details
splice.patch (splice.patch,321 bytes, patch)
2008-02-10 21:59 UTC, Brenden Matthews
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description toogle 2008-02-09 21:05:33 UTC
I got root on my sys-kernel/gentoo-sources-2.6.24 with this exploit:
% ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7db8000 .. 0xb7dea000
[+] root
# whoami
root

Reproducible: Always

Steps to Reproduce:
1. Compile exploit using gcc
2. Execute it
3. Got root...

Actual Results:  
Privilege escalation
Comment 1 toogle 2008-02-09 22:11:04 UTC
Created attachment 143059 [details]
Linux vmsplice Local Root Exploit
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2008-02-10 01:14:29 UTC
Yeah, fixed with http://tinyurl.com/38me8k
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2008-02-10 01:29:08 UTC
Erm... or not... this isn't properly fixed:

$ ./a.out 
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7dfe000 .. 0xb7e30000
Segmentation fault

$ ./a.out 
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e1e000 .. 0xb7e50000
[-] wtf

$ ./a.out 
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7dd7000 .. 0xb7e09000
[+] root

# whoami
root
Comment 4 Tobias Scherbaum (RETIRED) gentoo-dev 2008-02-10 14:03:15 UTC
*** Bug 209530 has been marked as a duplicate of this bug. ***
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2008-02-10 14:33:48 UTC
*** Bug 209533 has been marked as a duplicate of this bug. ***
Comment 6 Kim Højgaard-Hansen 2008-02-10 16:29:16 UTC
This should fix the issue:

From: Bastian Blank <bastian@waldi.eu.org>

The commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user
pointer access verification") added access_ok() to copy_from_user_mmap_sem()
which only ensures we can copy the struct iovecs from userspace to the kernel
but we also must check whether we can access the actual memory region pointed
to by the struct iovec to close the local root exploit.

Cc: <stable@kernel.org>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
Bastian, can I have your Signed-off-by for this, please? Oliver, Niki, can 
you please confirm this closes the hole?

 fs/splice.c |    3 +++
 1 file changed, 3 insertions(+)

Index: linux-2.6/fs/splice.c
===================================================================
--- linux-2.6.orig/fs/splice.c
+++ linux-2.6/fs/splice.c
@@ -1237,6 +1237,9 @@ static int get_iovec_page_array(const st
 		if (unlikely(!base))
 			break;
 
+		if (unlikely(!access_ok(VERIFY_READ, base, len)))
+			break;
+
 		/*
 		 * Get this base offset and number of pages, then map
 		 * in the user pages.
--
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2008-02-10 21:02:23 UTC
*** Bug 209602 has been marked as a duplicate of this bug. ***
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2008-02-10 21:13:21 UTC
(In reply to comment #6)

Yeah this looks finally like a working patch...
Comment 9 Brenden Matthews 2008-02-10 21:59:33 UTC
Created attachment 143165 [details, diff]
splice.patch

The patch from comment #6 works here on 2.6.22.  I had to modify the patch offset slightly, so I'm posting the resulting diff here for the benefit of others.
Comment 10 Christian Hoffmann (RETIRED) gentoo-dev 2008-02-11 09:25:11 UTC
If I didn't mis-interpret dsd's blog post [1] this should be fixed in gentoo-sources-2.6.23-r8 or gentoo-sources-2.6.24-r2, with the first one having been stabled on x86 and am64 already.
Vanilla linux-2.6.23.16 and 2.6.24.2 (containing the fix) have been released as well.

(Posting it here as well to keep this bug up-to-date)

[1] http://www.reactivated.net/weblog/archives/2008/02/critical-linux-kernel-vmsplice-security-issues/
Comment 12 Daniel Drake (RETIRED) gentoo-dev 2008-02-11 10:30:31 UTC
there were various patches thrown up, some did not fix the issue properly, some opened other holes. we took the ones that went upstream
Comment 13 Krzysztof Pawlik (RETIRED) gentoo-dev 2008-02-11 12:32:11 UTC
sys-kernel/tuxonice-sources 2.6.23-r10 (genpatches 9) and 2.6.24-r1 (genpatches 3) ready, both should go stable same time as gentoo-sources.
Comment 14 Christian Holler 2008-02-11 18:03:12 UTC
(In reply to comment #0)
> I got root on my sys-kernel/gentoo-sources-2.6.24 with this exploit:

I tested this on Gentoo Hardened Sources 2.6.18 and it worked as well.. I tried to fix it by uprading to 2.6.23 and applying the patches provided by the linux kernel   git repo but for some reason the exploit still works.. when will this be fixed in hardened-sources?

Regards,


Chris
Comment 15 Kerin Millar 2008-02-11 19:08:13 UTC
In response to Comment 14 - I would invite you to have a look at bug 207393 where the matter of updating and committing a new version of hardened-sources is being discussed.
Comment 16 Ulf Theobald 2008-02-12 00:10:25 UTC
Patch from gentoo-sources-2.6.24-r2 (1400_vmsplice-user-pointer.patch) also applies to xen-sources-2.6.20-r6 and fixed the security issue for me.
It would be great, if someone could supply an updated xen-sources package
Comment 17 Krzysztof Pawlik (RETIRED) gentoo-dev 2008-02-12 07:51:41 UTC
(In reply to comment #13)
> sys-kernel/tuxonice-sources 2.6.23-r10 (genpatches 9) and 2.6.24-r1 (genpatches
> 3) ready, both should go stable same time as gentoo-sources.

Only tuxonice-sources-2.6.24-r1 should be considered for stabilization wrt this bug, 2.6.23-r10 doesn't patch well (changes in stable branch broke tuxonice) and was removed.
Comment 18 Krzysztof Pawlik (RETIRED) gentoo-dev 2008-02-12 07:52:55 UTC
(In reply to comment #17)
> Only tuxonice-sources-2.6.24-r1 should be considered for stabilization wrt this
> bug

Big mistake: above should be 2.6.24-r2 (as -r2 contains fix for userui related problem).
Comment 19 Daniel Drake (RETIRED) gentoo-dev 2008-02-12 10:31:58 UTC
2.6.24 is nowhere near ready to go stable, pending on at least #207383 #208493, and probably a few more that I haven't caught up with yet
Comment 20 Kerin Millar 2008-02-12 13:12:21 UTC
I would invite the kernel team to consider commit 900cf086fd2fbad07f72f4575449e0d0958f860f to Linus' tree entitled "Be more robust about bad arguments in get_user_pages()". In particular, consider this remark from its author, Jonathan Corbet:

" ... how could a failure to check for *read* access turn into a root exploit? It turns out that it's a buffer overflow problem which is made easy by the way get_user_pages() is coded."

He's pointing out that the vmsplice() exploit is, in fact, just an access vector for a vulnerability that really resides in get_user_pages(). Moreover, it is quite plausible that get_user_pages() could be exploited by other presently unknown means in the kernel - for example, according to the PaX author, Direct I/O is a potential candidate but who knows what else ...

The aformentioned commit closes this loophole. Jonathan has also written an article about it here, for which a subscription is required until 21st Feb: http://lwn.net/Articles/268783/.

I think this patch is a prime candidate for genpatches-base and the stable queue. By committing this we could well be forearmed against future attacks that are based on the same principle. For the commit, see http://tinyurl.com/2l5xal. The patch itself is as follows:

diff --git a/mm/memory.c b/mm/memory.c
index e5628a5..717aa0e 100644 (file)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -989,6 +989,8 @@ int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
        int i;
        unsigned int vm_flags;
 
+       if (len <= 0)
+               return 0;
        /* 
         * Require read or write permissions.
         * If 'force' is set, we only require the "MAY" flags.
Comment 21 unnamedrambler 2008-02-12 13:50:08 UTC
Any news from the suspend2-sources maintainers regarding when a patch will be published?
Comment 22 Jukka Alasalmi 2008-02-12 14:23:24 UTC
By the way, why is there still no GLSA about this? Or will they only be published after the bug has been fixed?

As a reply comment #21, suspend2 has been renamed to tuxonice, and I understood that the same patch would apply there as would apply to gentoo sources. That's how I'm reading from comment #13 - correct me if I'm wrong (for example, if the stuff in comment #20 changes this somehow).
Comment 23 Daniel Drake (RETIRED) gentoo-dev 2008-02-12 14:39:25 UTC
(In reply to comment #20)
> I would invite the kernel team to consider commit
> 900cf086fd2fbad07f72f4575449e0d0958f860f 

thanks, queued.

(In reply to comment #22)
> By the way, why is there still no GLSA about this?

We do not do kernel GLSAs, sorry. Both the security and kernel projects don't have enough resources to coordinate them (too many kernels, and too many vulns because almost any small kernel bug is a vulnerability). We had a couple of developers who attempted to fill the "kernel security" role in the past but they burned out - it's a mindlessly boring unforgiving task which eats hours upon hours. Are you interested? :)
Comment 24 Jukka Alasalmi 2008-02-12 15:06:38 UTC
> We do not do kernel GLSAs, sorry.

Now that you said it, I noticed that gentoo security handbook says that "Keeping your kernel up-to-date is also recommended." - even though I'm not sure if it really points out that kernel GLSAs don't even exist at all.

> it's a mindlessly boring unforgiving task which eats hours upon hours.
> Are you interested? :)

The description sure sounds tempting :-) I guess I'm going to pass this one...
Comment 25 Krzysztof Pawlik (RETIRED) gentoo-dev 2008-02-12 16:14:05 UTC
(In reply to comment #22)
> As a reply comment #21, suspend2 has been renamed to tuxonice, and I understood
> that the same patch would apply there as would apply to gentoo sources. That's
> how I'm reading from comment #13 - correct me if I'm wrong (for example, if the
> stuff in comment #20 changes this somehow).

Yes, suspend2-sources is p.masked, pending removal. I've contacted Nigel (TuxOnIce upstream) about resyncing patch for 2.6.23.16.
Comment 26 Calum 2008-02-12 18:39:26 UTC
I do think it's a shame about the lack of kernel GLSAs.
The original reason was that there was going to be a shiny new tool called KISS, which was obviously much more exciting to work on. That never materialised though.

Perhaps not for every little thing - not for example for a DoS in some random RAID controller module only on FooBAR/08 architectures, but for local/remote roots that affect large percentages of users, it would be good.

After I've installed a machine, I set up a cron job that emails me the output of glsa-check -l affected, and only update software that's affected.

I find it strange that the main, core component that everything else runs on is excluded from the Gentoo **Linux** "Security Advisories".

The first I heard of this was on Slashdot, and that's not the best way to get your news. Yes, there are other ways to get this info. Not everyone has time to trawl through mailing lists, and Bugzillas, etc though. GLSAs are a nice method.

Anyway, I mentioned this on the security mailing list a couple of times, and got shouted down, so I'll don my suit now.
Comment 27 Sune Kloppenborg Jeppesen gentoo-dev 2008-02-12 19:01:25 UTC
While you install the kernel sources with emerge, you don't actually install the kernel with emerge, so kernels are treated special. AFAIK glsa-check will only check if you have some vulnerable kernel sources installed and nothing about the running kernel.
Comment 28 Jon Portnoy 2008-02-12 19:57:22 UTC
I realize there are a metric shitton of kernels in the tree but it seems to me it would make sense to make _some_ attempt to ensure users are aware of things like a root exploit in the Linux part of Gentoo Linux. "It can't be fixed with just emerge blah so we don't GLSA it" is interesting to put it mildly. I'm interested though, maybe I'd even consider a return to Gentoo: why does doing kernel security even vaguely right eat hours upon hours?

It's fixed in the tree for at least some kernels, why is it impossible to notify users of which kernels are broken and which are fixed?

And do you really think it's a good idea for serious distributions to quietly fix root exploits in the kernel without notifying users?
Comment 29 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-02-12 20:26:36 UTC
(In reply to comment #26)
> I do think it's a shame about the lack of kernel GLSAs.
> The original reason was that there was going to be a shiny new tool called
> KISS, which was obviously much more exciting to work on. That never
> materialised though.
> 
> Perhaps not for every little thing - not for example for a DoS in some random
> RAID controller module only on FooBAR/08 architectures, but for local/remote
> roots that affect large percentages of users, it would be good.
> 
> After I've installed a machine, I set up a cron job that emails me the output
> of glsa-check -l affected, and only update software that's affected.
> 
> I find it strange that the main, core component that everything else runs on is
> excluded from the Gentoo **Linux** "Security Advisories".
> 
> The first I heard of this was on Slashdot, and that's not the best way to get
> your news. Yes, there are other ways to get this info. Not everyone has time to
> trawl through mailing lists, and Bugzillas, etc though. GLSAs are a nice
> method.
> 
> Anyway, I mentioned this on the security mailing list a couple of times, and
> got shouted down, so I'll don my suit now.
> 

Well, I won't shout at you, I'll just point you to comment #23 on this bug...I think everyone would like to have kernel GLSA, but remember, unlike Ubuntu or Fedora, here no one gets paid to do the job, and god knows tracking kernel issues on a dozen different patchset is all but an exciting task...
Comment 30 Sune Kloppenborg Jeppesen gentoo-dev 2008-02-12 20:50:18 UTC
@Jon: You're more than welcome to return to help with kernel security. I'd buy you beer any day I meet you for that:)

Wrt informing users I think a news item on the front page and an announce mail is going to happen.
Comment 31 Robert Buchholz (RETIRED) gentoo-dev 2008-02-12 20:57:08 UTC
Can we please discuss Gentoo's kernel security process off of this bug? I'm happy for any insights, offers, and ideas, if they go to the security mailing list, or the security@g.o alias.

Calum, if you are really interested in helping out within kernel security, please let me know in private.
Comment 32 Kerin Millar 2008-02-12 21:56:25 UTC
Of those kernel ebuilds that leverage genpatches-base (all of the 2.6 versions apparently), figuring out which are vulnerable isn't so hard. Let's assume the following:

* < 2.6.17 is not vulnerable (debatable)
* All other version are except for:
    2.6.23 + genpatches-base-2.6.23-9
    2.6.24 + genpatches-base-2.6.24-3

Now for a cheeky one-liner to look for those that are vulnerable:

$ cd /usr/portage/sys-kernel && find -iname "*.ebuild" -exec grep -H GENPATCHES_VER '{}' \; | cut -d/ -f3- | perl -ne 'm/(.+)\-2\.6\.(\d+)(?:\-r(\d+))?.+?"(\d+)"/ && (($2 >= 17 && $2 < 23) || ($2 == 24 && $4 < 3) || ($2 == 23 && $4 < 9)) && print "$1-2.6-$2" . (($3)?"-r$3":"") . " [genpatches-2.6.$2-$4]\n"' | sort
gentoo-sources-2.6-19-r5 [genpatches-2.6.19-6]
gentoo-sources-2.6-19-r7 [genpatches-2.6.19-8]
gentoo-sources-2.6-20-r10 [genpatches-2.6.20-14]
gentoo-sources-2.6-21-r4 [genpatches-2.6.21-6]
gentoo-sources-2.6-22 [genpatches-2.6.22-1]
gentoo-sources-2.6-22-r1 [genpatches-2.6.22-2]
gentoo-sources-2.6-22-r10 [genpatches-2.6.22-11]
gentoo-sources-2.6-22-r2 [genpatches-2.6.22-3]
gentoo-sources-2.6-22-r3 [genpatches-2.6.22-4]
gentoo-sources-2.6-22-r4 [genpatches-2.6.22-5]
gentoo-sources-2.6-22-r5 [genpatches-2.6.22-6]
gentoo-sources-2.6-22-r6 [genpatches-2.6.22-7]
gentoo-sources-2.6-22-r7 [genpatches-2.6.22-8]
gentoo-sources-2.6-22-r8 [genpatches-2.6.22-9]
gentoo-sources-2.6-22-r9 [genpatches-2.6.22-10]
gentoo-sources-2.6-23 [genpatches-2.6.23-1]
gentoo-sources-2.6-23-r1 [genpatches-2.6.23-2]
gentoo-sources-2.6-23-r2 [genpatches-2.6.23-3]
gentoo-sources-2.6-23-r3 [genpatches-2.6.23-4]
gentoo-sources-2.6-23-r4 [genpatches-2.6.23-5]
gentoo-sources-2.6-23-r5 [genpatches-2.6.23-6]
gentoo-sources-2.6-23-r6 [genpatches-2.6.23-7]
gentoo-sources-2.6-23-r7 [genpatches-2.6.23-8]
gentoo-sources-2.6-24 [genpatches-2.6.24-1]
gentoo-sources-2.6-24-r1 [genpatches-2.6.24-2]
hardened-sources-2.6-20-r10 [genpatches-2.6.20-19]
hardened-sources-2.6-20-r6 [genpatches-2.6.20-13]
hardened-sources-2.6-23-r4 [genpatches-2.6.23-6]
hardened-sources-2.6-23-r6 [genpatches-2.6.23-7]
rsbac-sources-2.6-18 [genpatches-2.6.18-3]
rsbac-sources-2.6-18-r1 [genpatches-2.6.18-3]
rsbac-sources-2.6-19 [genpatches-2.6.19-5]
rsbac-sources-2.6-19-r1 [genpatches-2.6.19-7]
rsbac-sources-2.6-21 [genpatches-2.6.21-4]
rsbac-sources-2.6-21-r1 [genpatches-2.6.21-4]
suspend2-sources-2.6-21-r7 [genpatches-2.6.21-6]
suspend2-sources-2.6-22-r2 [genpatches-2.6.22-6]
tuxonice-sources-2.6-23 [genpatches-2.6.23-1]
tuxonice-sources-2.6-23-r1 [genpatches-2.6.23-2]
tuxonice-sources-2.6-23-r2 [genpatches-2.6.23-3]
tuxonice-sources-2.6-23-r3 [genpatches-2.6.23-4]
tuxonice-sources-2.6-23-r4 [genpatches-2.6.23-4]
tuxonice-sources-2.6-23-r5 [genpatches-2.6.23-5]
tuxonice-sources-2.6-23-r6 [genpatches-2.6.23-6]
tuxonice-sources-2.6-23-r7 [genpatches-2.6.23-7]
tuxonice-sources-2.6-23-r8 [genpatches-2.6.23-7]
tuxonice-sources-2.6-23-r9 [genpatches-2.6.23-7]
tuxonice-sources-2.6-24 [genpatches-2.6.24-1]
usermode-sources-2.6-18 [genpatches-2.6.18-1]
usermode-sources-2.6-18-r1 [genpatches-2.6.18-8]
usermode-sources-2.6-18-r2 [genpatches-2.6.18-8]
xen-sources-2.6-18-r6 [genpatches-2.6.18-10]
xen-sources-2.6-18-r7 [genpatches-2.6.18-10]
xen-sources-2.6-18-r8 [genpatches-2.6.18-10]
xen-sources-2.6-20-r5 [genpatches-2.6.20-19]
xen-sources-2.6-20-r6 [genpatches-2.6.20-19]

I must say that it seems as though a little tree de-crufting wouldn't go amiss.

We're missing vserver-sources here as it uses an odd version numbering scheme. Still, a casual glance at all versions in portage makes it plainly obvious that they are vulnerable:

$ cd /usr/portage/sys-kernel/vserver-sources && for ebuild in *.ebuild; do CKV=$(grep ^CKV $ebuild | cut -d\" -f2); GPV=$(grep ^K_GENPATCHES_VER $ebuild | cut -d\" -f2); echo "$ebuild [genpatches-base-$CKV-$GPV]"; done
vserver-sources-2.2.0-r1.ebuild [genpatches-base-2.6.20-13]
vserver-sources-2.2.0.4.ebuild [genpatches-base-2.6.22-10]
vserver-sources-2.2.0.5.ebuild [genpatches-base-2.6.22-10]
vserver-sources-2.3.0.27.ebuild [genpatches-base-2.6.22-10]
vserver-sources-2.3.0.29.ebuild [genpatches-base-2.6.22-10]
Comment 33 Jakub Moc (RETIRED) gentoo-dev 2008-02-13 13:10:02 UTC
*** Bug 209992 has been marked as a duplicate of this bug. ***
Comment 34 Benedikt Böhm (RETIRED) gentoo-dev 2008-02-13 14:27:36 UTC
(In reply to comment #32)
> We're missing vserver-sources here as it uses an odd version numbering scheme.
> Still, a casual glance at all versions in portage makes it plainly obvious that
> they are vulnerable:
> 
> $ cd /usr/portage/sys-kernel/vserver-sources && for ebuild in *.ebuild; do
> CKV=$(grep ^CKV $ebuild | cut -d\" -f2); GPV=$(grep ^K_GENPATCHES_VER $ebuild |
> cut -d\" -f2); echo "$ebuild [genpatches-base-$CKV-$GPV]"; done
> vserver-sources-2.2.0-r1.ebuild [genpatches-base-2.6.20-13]
> vserver-sources-2.2.0.4.ebuild [genpatches-base-2.6.22-10]
> vserver-sources-2.2.0.5.ebuild [genpatches-base-2.6.22-10]
> vserver-sources-2.3.0.27.ebuild [genpatches-base-2.6.22-10]
> vserver-sources-2.3.0.29.ebuild [genpatches-base-2.6.22-10]

2.2.0.6 (just commited) is not vulnerable
Comment 35 RB 2008-02-13 20:02:05 UTC
Tested per Kerin's IRC request:

========================================
[test@dev-01 ~] uname -a
Linux dev-01 2.6.23-hardened-r7 #4 SMP PREEMPT Wed Feb 13 11:55:39 MST 2008 i686 Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux
[test@dev-01 ~] gcc -static -Wno-format -o milw0rm-5092 copy_from_user_mmap_sem.c
[test@dev-01 ~] ./milw0rm-5092
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x57ed9000 .. 0x57f0b000
[-] vmsplice: Bad address
[test@dev-01 ~] gcc -static -Wno-format -o milw0rm-5093 vmsplice_to_pipe.c
[test@dev-01 ~] ./milw0rm-5093
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] addr: 0x16b64
[-] wtf
========================================

Couldn't get milw0rm 5092 (CVE-2008-0600) to get to 'wtf'.  I have turned off CONFIG_PAX_UDEREF, CONFIG_PAX_ASLR, and CONFIG_GRKERNSEC_HIDESYM, as well as made /proc/kallsyms world-readable.

So, 0010 and 0600 (copy_from_user_mmap_sem and vmsplice_to_pipe, respectively) were tested, but I couldn't find any code against 0009 (vmsplice_to_user).
Comment 36 Jakub Moc (RETIRED) gentoo-dev 2008-02-14 17:44:24 UTC
*** Bug 210156 has been marked as a duplicate of this bug. ***
Comment 37 Guillaume Destuynder (RETIRED) gentoo-dev 2008-02-15 17:21:11 UTC
both fixes are in rsbac-sources-2.6.23 on cvs ~arch as well now
(note, the fix is in the RSBAC patch so checking genpatch version will be unaccurate for this one)
Comment 38 geek 2008-02-15 17:50:12 UTC
*** Bug 210263 has been marked as a duplicate of this bug. ***
Comment 39 Jakub Moc (RETIRED) gentoo-dev 2008-02-17 11:11:01 UTC
*** Bug 210451 has been marked as a duplicate of this bug. ***
Comment 40 Krzysztof Pawlik (RETIRED) gentoo-dev 2008-02-17 20:23:50 UTC
(In reply to comment #25)
> Yes, suspend2-sources is p.masked, pending removal. I've contacted Nigel
> (TuxOnIce upstream) about resyncing patch for 2.6.23.16.

tuxonice-sources-2.6.23-r10.ebuild:
Revision bump for genpatches 9, TuxOnIce 3.0-rc5 for 2.6.23.16.
Comment 41 Benedikt Böhm (RETIRED) gentoo-dev 2008-02-20 12:07:01 UTC
vserver-sources-2.2.0.6 stable, vulnerable versions removed, devel branch 2.3 is not fixed yet but masked anyway for testing
Comment 42 Kerin Millar 2008-02-20 12:17:04 UTC
Adding a reference to CVE-2008-0600 to the summary. I have no idea why it wasn't there before but it should be.
Comment 43 Peter Volkov (RETIRED) gentoo-dev 2008-03-19 11:28:59 UTC
hppa, seems that your kernel is still affected by this bug. Please check this bug, to avoid release with this flaw. Thank you.
Comment 44 Jeroen Roovers gentoo-dev 2008-03-20 03:58:35 UTC
(In reply to comment #43)
> hppa, seems that your kernel is still affected by this bug. Please check this
> bug, to avoid release with this flaw. Thank you.

If you mean hppa-sources, that's package.masked in accordance with bug #202391.
Comment 45 Peter Volkov (RETIRED) gentoo-dev 2008-03-20 08:43:14 UTC
Ah, I see. Thank you Jeroen. UnCC'ing hppa.

Then seems that the only affected kernels remain are: 
cell-sources, mips-sources, usermode-sources.

CC'ing maintainers: please check your kernels. I think it's worth to have this this bug fixed even if kernels are security unsupported/unstable...  Thank you in advance.
Comment 46 Luca Barbato gentoo-dev 2008-03-20 09:44:32 UTC
cell sources could be p.masked since .24 has most of the code needed to get a bootable ps3/cell system and I still prefer tracking the git branch.

If the other people in the team want I could try to get a .25 snapshot.

Comment 47 Mike Pagano gentoo-dev 2008-03-20 14:36:54 UTC
(In reply to comment #46)
> If the other people in the team want I could try to get a .25 snapshot.
> 

IMHO, less kernels to maintain (and track bugs in) is better than more. If you think 2.6.24 contains enough support for cell, I would be for masking this,


Comment 48 Luca Barbato gentoo-dev 2008-03-24 02:04:41 UTC
I added an updated .24.3+cell/ps3 related improvement, that should solve the issue for cell-sources.
Comment 49 Peter Volkov (RETIRED) gentoo-dev 2008-06-20 19:33:44 UTC
cell-sources and usermode-sources are not so important for release. So we are done with this bug.
Comment 50 Benedikt Böhm (RETIRED) gentoo-dev 2009-01-10 21:37:27 UTC
there are no more vulnerable versions of vserver-sources
Comment 51 Peter Volkov (RETIRED) gentoo-dev 2009-03-03 08:00:13 UTC
For a long time, recent mips sources have this issues fixed ...
Comment 52 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2018-04-04 17:31:56 UTC
There are no longer any 2.x kernels available in the repository with the exception of sys-kernel/xbox-sources which is unsupported by security.