A small C program can crash the linux kernel effectivly halting the system. This can be done by any user with local or remote shell access -- does NOT requre the user to be root.
Created attachment 33167 [details] Program that crashes the kernel This program will crash 2.4.xx and 2.6.xx kernels. Can be run by any user.
Created attachment 33168 [details, diff] Patch for vanilla 2.4.26 kernels This patch for signal.c makes the kernels secure against the evil code
Created attachment 33169 [details, diff] Patch for 2.4.21
kernel team -- please review/patch.
The suggested patch is pretty nasty. See the LKML thread "Subject: timer + fpu stuff locks my console race" for better suggestions, in particular "[PATCH] fix for Re: timer + fpu stuff locks my console race" by Andi Kleen <ak@muc.de>.
2.6.6 is not vulnerability.
Both patches are pretty nasty - the attached one causes kernel panics [ @Ref: http://lkml.org/lkml/2004/6/12/64 ] and Andi Kleen's [ @Ref: http://lkml.org/lkml/2004/6/12/88 ] comes with a big "This may break some code or it may not. We'll see." warning. There's also http://lkml.org/lkml/2004/6/12/81 which does work properly, but that doesn't solve the whole issue and may leave related bugs open to exploitation. If somebody has some more patches please reference or add them here and I'll consider them. Waiting for an upstream kernel decision for now then; marking as such in the Status Whiteboard...
solar posted this recently also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15905
*** Bug 53792 has been marked as a duplicate of this bug. ***
See Bug 53792 There, I have attached the upstream fix from 2.6.7-rc3-bk5.
I've tested this bug one more time. 2.6.6 is vulnerability when you compile its without any CFLAGS. When I added -Wall -pedantic -ansi -Os it doesn't work :)
-Wall, -pedantic and -ansi should not change the generated code in any way. Those options just give additional warnings and disable some GNU extensions. So it's only -Os that could make a difference. However, this is pure coincidence and you should not rely on it. The bug might just be harder to trigger or reappear with different compiler versions or -march settings. To be safe, you have to patch your kernel!
http://linuxreviews.org/news/2004-06-11_kernel_crash/index.html This is where the vulnerability first appeared. It lists all currently know bad kernels (included 2.6.6 vanilla and 2.6.5 gentoo), as well as known safe kernels. What's interesting? Some of the gentoo patchsets are proven safe, and others are proven bad. What the difference is is not known.
Created attachment 33230 [details, diff] Better fix to the Problem maybe?
IMPORTANT: amd64 is affected as well. The fix is the same as on x86 (it's included in 2.6.7-rc3-bk6). The file that needs the change is include/asm-x86_64/i387.h
I have just confirmed that Mandrake's sources are vulnerable as well. Mandrake's linux-2.6.3-13mdk crashes too on my Gentoo box. Does any of the 2.6 kernels from Portage do better? I have tried the current Gentoo dev-kernel, aa-sources and ck-sources as well as Vanilla 2.6.4 and they all failed. regards, Tobias
Here is an exact description of what is going on inside the kernel: http://masmforum.com/website/tutorials/fptute/fpuchap3.htm#fclex Someone *should* have read this four years ago, before coding the clear_fpu() macro...
openmosix-sources-2.4.22-r8 (masked for a while) commited with fix from comment #14 tested with exploit from comment #1
This crashses the 2.6.4-ck1 sources too. On Hyperthreading enabled PIV it takes 2 instances of the program to crash the kernel, like in SMP sysems. I'm confirming the last patch worked for me.
The newest Fedora Kernel seem to have a fix: From: Mark Eggers <mdeggers@earthlink.net> To: fedora-list@redhat.com Subject: Re: Crash exploit Date: Mon, 14 Jun 2004 13:28:35 -0700 The latest kernel (2.6.6-1.435) seems to solve this problem. I can compile the offending code, but when running it all I get is trash on a terminal window. The system stays up, and a simple Ctrl-C stops the program. Nice, fast work folks! /mde/ Just came in on the Fedora list. regards, Tobias
The fix outlined in attachment id=33230 was personally committed by Linus to the 2.6 branch, and by Marcelo to the 2.4 branch. See: http://linux.bkbits.net:8080/linux-2.5/diffs/include/asm-i386/i387.h@1.16?nav=index.html Might I be so bold as to suggest that a GLSA/sources bump is in order?
Hi, in regard to the GLSA/sources bump request I might just add that it would be very helpful if current versions of kernel trees should be patched too please. Stepping up a version is not an option for many people, especially for people with NVidia kernel module issues. I'll be able to patch my current sources for myself if need be but people should be able to run a version of a tree without jumping up anytime a security flaw is discovered in them. Another release version of current trees would therefor be kindly appreciated! thanks a lot, Tobias
I confirm that the patch for i387.h works on my system: Linux ligezin 2.6.5-gentoo-r1 #1 SMP Mon Jun 14 23:37:34 CEST 2004 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux
grsec-sources-2.4.26.2.0-r3 patched with attachment #33230 [details, diff]
I've patched more-or-less everything now, meaning every kernel in Portage except non-x86 kernels such as {alpha, ia64, mips, ...}-sources which are deemed to not be used by x86 users and the following that need to be patched by the relevant maintainers are left to do... gentoo-dev-sources - CCing steel300. -- The following kernels are also outstanding on bug #47881. If they are not patched within a reasonable timeframe; then Gentoo Security may security-mask the packages. hardened-dev-sources - Hardened is already on the CC. hardened-sources - Likewise. selinux-sources - Adding pebenito to the CC.
selinux-sources fixed for this and for #47881
Hello, dear gods of Gentoo. I'm the wiero who wrote http://linuxreviews.org/news/2004-06-11_kernel_crash/ and Opened: 2004-06-13 06:32 PST his bug. I would just like to say Thank You for all your wonderfull efforts, and I am very impressed on how fast and smooth this got resolved. Again, thank you all who used your valuable time and energy on solving this issue, giving feedback, testing and so forth. Truely amazing.
hardened-dev-sources is fixed.
*** Bug 54366 has been marked as a duplicate of this bug. ***
2.6.7 ebuild is out, so 2.6 is now safe.
<i>2.6.7 ebuild is out, so 2.6 is now safe.</i> Actually, that means that only 2.6.7 is safe - unless the patch is backported. Also, gentoo-dev-sources hasn't been updated yet... <prays>Will the patch be backported to gentoo-dev-sources-2.6.X?</prays> Just checked packages.gentoo.org - saw only development-sources at 2.6.7. Thanks for all the work!
No, I will not backport fixes to older kernels, when newer ones are out, sorry. That way lies madness...
[Greg: I think that we may not be talking about the same thing. I'm talking about sys-kernel/gentoo-dev-sources, not sys-kernel/development-sources Your comment seemed to imply that vanilla-2.6.7 was out so that any backporting for *any* 2.6 kernel in sys-kernel/ would therefore not happen. But "foreporting" hasn't happend for gentoo-dev-sources yet. Or do you also speak for the gentoo-dev-sources team? Apologies if this is not what you meant.] Just to be clear, I humbly request that, like the other major kernel ebuilds (like the 2.4 series), gentoo-dev-sources have 2.6.5 updated to -r2, rather than being forced to also bump up to an entirely new kernel version to just get a narrowly-focused security fix. Indeed, I also eagerly wait for gentoo-dev-sources-2.6.7, but some people are a bit more conservative on some systems. But that update is also not available currently for gentoo-dev-sources. Of course, as soon as I post this, it will have just been added to Portage ;)... My request is really a "me too" to #22 above, focused on the last (I think) kernel package in Gentooland to not be updated yet.
No, I was talking about gentoo-dev-sources, for which there is a 2.6.7 release now available. I will not backport such fixes to older kernels, as I said, that way lies madness. As 2.6.7 has so many fixes over 2.6.5, I do not see why you would not want to upgrade this. If not, you can always apply the patch yourself :)
Oh, and to be clear, at this time I _do_ speak for the gentoo-dev-sources team, as no one else seems to be available at this time...
"I will not backport such fixes to older kernels, as I said, that way lies madness." I have to point out that it's also madness to force a version bump on the majority of users when you already know that essential kernel modules such as nvidia won't work with 2.6.7. As long as there is no solution for this problem to come out of Portage ready to use by the majority of Gentoo users I'd strongly advise to maintain 2.6.5-gentoo with another release. If you make up a GLSA then I'd suggest giving some hints on how to patch 2.6.5-gentoo-r1. I have found out by now myself but you're going to confuse a whole lot of Gentoo users by just making the version bump and leading them blindly into NVidia trouble. regards, Tobias
Tobias, I suggest you check that you have 4KB kernel stacks disabled in the 2.6.7 kernel. Because I have it working here. (Note however, that the nVidia kernel module is not open-source, and not supported by the linux kernel authors and maintainers in *any* way. That's why on load, you get a message that your kernel is tainted. It means, from now on, you are at nVidia's mercy if things fall apart.) Linux prometheus 2.6.7-bk2 #1 SMP Sat Jun 19 16:15:06 IST 2004 i686 AMD Athlon(TM) MP 1800+ AuthenticAMD GNU/Linux direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.3
As discussed, the nvidia driver should work on 2.6.7, just as well as it works on other kernels. Also, as we have no control over how well the nvidia driver works, I really can not do anything about it. So again, please use 2.6.7
As long as development of kernel 2.6 doesn't slow down, there is no point in sticking with older versions. Every day, many bugs - some of them critical - are fixed in Linux 2.6. Everyone using a kernel in this early stage of deployment should be aware of that and alway use the latest version. BTW: When using intrusive, binary only drivers, one additional Local DoS is nothing I would worry about.
I have the 4KB kernel stacks disabled as I answered "no" to this option when I ran "make oldconfig" across my 2.6.5 config file. It won't load the nvidia module. I have used the nvidia-kernel that came with the current version of the Portage tree. In my opinion things should work "out of the box" if they are not masked in Portage. If they don't then mask them. I am well aware that any new version of the kernel fixes stuff. But it is also true that any new version of a kernel introduces new issues as well. The Vanilla 2.6.6 release for example has issues with my IDE controller that magically disappeared with 2.6.7-gentoo but haven't been there with 2.6.5-gentoo-r1 in the first place. There is a sound reason most other distributions stick to one release of a kernel for a very long time until they make a version bump. Making a version bump just to fix a security hole is NOT the optimal solution and speaking plainly doesn't credit Gentoo as a distribution. It's totally OK if newer versions are offered in Portage as they become available but I'd like to slow down the version bumping and put more time into testing a new kernel release before making it the standard in Portage and neglecting security fixes to slightly older releases. regards, Tobias
Nobody really forces you to upgrade anything.
hardened-sources masked until it can be attended to, removing hardened@ from cc
Will this policy continue if and when some 2.6.X kernel from gentoo-dev-sources becomes "stable" and is placed in gentoo-sources? Or will the current 2-3 version backporting policy on gentoo-sources (2.4.X) carry over to the new upstream branch (2.6.X)? I'd like to know this, so I can use that knowledge to make decisions about future servers and workstations I build for clients and employers, as well as myself. Thanks for your time, work and attention.
The 2.6 policy is to follow the mainline kernel.org kernel as close as possible. We do this because we want to take advantage of all of the different bug fixes, and driver updates in the main kernel trees, and because we do not have the person power to constantly backport fixes to an older kernel. Other distros do keep on one kernel version because of lots of reasons, none of which apply to the Gentoo project. Hope this helps explain the issues.
Thank you, Greg. As I was reading more in the mailing lists and the forums on the need for more kernel devs on the kernel team, I was beginning to realize why you said that backporting would be "madness"...
Greg, I can totally understand you motives. But I have an idea that might solve the problem and suite everybody, the Gentoo developers with their limited resources and Gentoo users who want a stable 2.6 kernel without too many changes in a short time: I am working on an ebuild for Mandrake's kernel tree. Mandrake is using 2.6.3 as their base kernel for Mandrake 10 and I've been running it on my Gentoo box for almost 4 weeks now. It's rock stable and performs better than Vanilla. It also comes with a lot of third-party drivers/contributions (Free/OS). We could proceed like this: offer Mandrake's sources and just go along with Mandrake's update policy, thus offering a stable 2.6 kernel that doesn't version bump and is predictable. The effort to patch these sources is marginal since all we have to do is wait for Mandrake to release their patches. They will have done the testing too, so as soon as they update we can do too. It's not a problem to extract the tree out of their source installation RPM and there is another source RPM with the original 2.6.3 tree and the diffs from their patchset. It's on every Mandrake FTP mirror. People who want to try Mandrake's source can go to mandrake-sources.weisserth.org too to download the tree in tar.bz2 format or just grab them from Mandrake's FTP mirror in RPM format. Let me know what you think of the idea, especially the devs. regards, Tobias
We used to do this with redhat's kernels. Best to consult with whoever did the removing to see why it was dropped.
If you wish to create a new kernel ebuild that tracks mandrake's kernel, great, please do so. But then you are at the mercy of that distro's kernel team, and can not get any support from anyone here :)
Greg, that's exactly the idea. The idea is to use what's already there and make it available to Gentoo users in order to a) ease the dev team's burden b) while at the same time offer a stable and predictable 2.6 kernel tree I deliberately chose Mandrake since they grant easy access to their sources without deliberate obstruction and Mandrake is widely used both for desktop and server use. Matters ouwld look differently with "experimental" sources like Fedora's where "at the mercy of" has a more negative impact. I'll see that I'll have an ebuild ready as soon as I have finished my exams at university. That'll be within the next week. May I contact developers with specific requests how to write the ebuild for external kernel sources? I have created a single ebuild an am only vaguely familiar with the the specifics. Who has been responsible for the Red Hat ebuild that has been available until recently? I guess that ebuild would be a good starting point for me. I'd really like to have it. Thanks, Tobias
Tobias, this is an ebuild for SuSE kernel: http://dev.gentoo.org/~voxus/suse-sources-2.6.4.ebuild hope, it helps
*** Bug 54992 has been marked as a duplicate of this bug. ***
* poke * is there going to be an official patch for the 2.4.26 in portage anytime soonish?
Which 2.4.26 sources are you talking about ? If you mean gentoo-sources, this bug was fixed in 2.4.26-r2. GLSA will be published as soon as we crush the other vulnerabilities lying around.
GLSA 200407-02; http://article.gmane.org/gmane.linux.gentoo.announce/382; closing as FIXED.
