Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 53804 - sys-kernel/*: 20 lines of C code can crash the kernel
Summary: sys-kernel/*: 20 lines of C code can crash the kernel
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: x86 Linux
: Highest critical (vote)
Assignee: Gentoo Security
Whiteboard: A3 [kernel]
: 53792 54366 54992 (view as bug list)
Depends on:
Reported: 2004-06-13 06:32 UTC by xiando
Modified: 2011-10-30 22:42 UTC (History)
14 users (show)

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

Program that crashes the kernel (crash.c.txt,529 bytes, text/plain)
2004-06-13 06:33 UTC, xiando
no flags Details
Patch for vanilla 2.4.26 kernels (signal.c-2.4.26.patch.txt,569 bytes, patch)
2004-06-13 06:34 UTC, xiando
no flags Details | Diff
Patch for 2.4.21 (signal.c-2.4.21.patch.txt,574 bytes, patch)
2004-06-13 06:35 UTC, xiando
no flags Details | Diff
Better fix to the Problem maybe? (linux-2.4.26-signal-exploit-2.patch,371 bytes, patch)
2004-06-14 08:33 UTC, Christian Stuke
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description xiando 2004-06-13 06:32:31 UTC
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.
Comment 1 xiando 2004-06-13 06:33:44 UTC
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.
Comment 2 xiando 2004-06-13 06:34:32 UTC
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
Comment 3 xiando 2004-06-13 06:35:01 UTC
Created attachment 33169 [details, diff]
Patch for 2.4.21
Comment 4 Kurt Lieber (RETIRED) gentoo-dev 2004-06-13 06:38:04 UTC
kernel team -- please review/patch.  
Comment 5 Ciaran McCreesh 2004-06-13 08:11:00 UTC
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 <>.
Comment 6 Karol Wojtaszek (RETIRED) gentoo-dev 2004-06-13 09:29:23 UTC
2.6.6 is not vulnerability.
Comment 7 Tim Yamin (RETIRED) gentoo-dev 2004-06-13 09:37:00 UTC
Both patches are pretty nasty - the attached one causes kernel panics [ @Ref: ] and Andi Kleen's [ @Ref: ] comes with a big "This may break some code or it may not. We'll see." warning.

There's also 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...
Comment 8 SpanKY gentoo-dev 2004-06-13 10:26:34 UTC
solar posted this recently also:
Comment 9 Seemant Kulleen (RETIRED) gentoo-dev 2004-06-13 11:15:24 UTC
*** Bug 53792 has been marked as a duplicate of this bug. ***
Comment 10 Marc Ballarin 2004-06-13 11:16:42 UTC
See Bug 53792

There, I have attached the upstream fix from 2.6.7-rc3-bk5.
Comment 11 Karol Wojtaszek (RETIRED) gentoo-dev 2004-06-13 12:23:19 UTC
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 :)
Comment 12 Marc Ballarin 2004-06-13 12:59:44 UTC
-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!
Comment 13 John Lyon 2004-06-14 08:33:13 UTC

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.
Comment 14 Christian Stuke 2004-06-14 08:33:55 UTC
Created attachment 33230 [details, diff]
Better fix to the Problem maybe?
Comment 15 Marc Ballarin 2004-06-14 09:13:01 UTC
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
Comment 16 Tobias Weisserth 2004-06-14 11:56:07 UTC
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.

Comment 17 Marc Ballarin 2004-06-14 12:40:28 UTC
Here is an exact description of what is going on inside the kernel:

Someone *should* have read this four years ago, before coding the clear_fpu() macro...
Comment 18 Konstantin Arkhipov (RETIRED) gentoo-dev 2004-06-14 13:03:25 UTC
openmosix-sources-2.4.22-r8 (masked for a while) commited with fix from comment #14
tested with exploit from comment #1
Comment 19 V. Seguí 2004-06-14 13:38:15 UTC
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.
Comment 20 Tobias Weisserth 2004-06-14 13:56:12 UTC
The newest Fedora Kernel seem to have a fix:

From: Mark Eggers <>
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!


Just came in on the Fedora list.

Comment 21 Kerin Millar 2004-06-14 14:24:59 UTC
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:

Might I be so bold as to suggest that a GLSA/sources bump is in order?
Comment 22 Tobias Weisserth 2004-06-14 14:49:13 UTC

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,
Comment 23 Wouter Horré 2004-06-14 14:53:55 UTC
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
Comment 24 solar (RETIRED) gentoo-dev 2004-06-15 10:06:30 UTC
grsec-sources- patched with attachment #33230 [details, diff]
Comment 25 Tim Yamin (RETIRED) gentoo-dev 2004-06-15 13:32:17 UTC
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.
Comment 26 Chris PeBenito (RETIRED) gentoo-dev 2004-06-15 13:59:06 UTC
selinux-sources fixed for this and for #47881
Comment 27 xiando 2004-06-15 14:51:01 UTC
Hello, dear gods of Gentoo.

I'm the wiero who wrote

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.
Comment 28 Brandon Hale (RETIRED) gentoo-dev 2004-06-15 21:04:20 UTC
hardened-dev-sources is fixed.
Comment 29 Sven Wegener gentoo-dev 2004-06-18 15:49:09 UTC
*** Bug 54366 has been marked as a duplicate of this bug. ***
Comment 30 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-06-18 16:54:53 UTC
2.6.7 ebuild is out, so 2.6 is now safe.
Comment 31 Jesse Adelman 2004-06-18 17:06:10 UTC
<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 - saw only development-sources at 2.6.7. Thanks for all the work!
Comment 32 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-06-18 17:13:32 UTC
No, I will not backport fixes to older kernels, when newer ones are out, sorry.

That way lies madness...
Comment 33 Jesse Adelman 2004-06-18 18:03:42 UTC
[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.
Comment 34 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-06-18 19:42:05 UTC
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 :)
Comment 35 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-06-18 19:43:34 UTC
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...
Comment 36 Tobias Weisserth 2004-06-19 08:31:08 UTC
"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.

Comment 37 Tony Vroon (RETIRED) gentoo-dev 2004-06-19 08:42:19 UTC
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
Comment 38 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-06-19 09:09:26 UTC
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
Comment 39 Marc Ballarin 2004-06-19 09:25:35 UTC
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.
Comment 40 Tobias Weisserth 2004-06-19 10:40:59 UTC
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.

Comment 41 Luca Barbato gentoo-dev 2004-06-19 11:07:50 UTC
Nobody really forces you to upgrade anything.
Comment 42 Joshua Brindle (RETIRED) gentoo-dev 2004-06-19 12:11:04 UTC
hardened-sources masked until it can be attended to, removing hardened@ from cc
Comment 43 Jesse Adelman 2004-06-19 12:38:36 UTC
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.
Comment 44 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-06-21 11:10:57 UTC
The 2.6 policy is to follow the mainline 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.
Comment 45 Jesse Adelman 2004-06-21 11:16:22 UTC
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"...
Comment 46 Tobias Weisserth 2004-06-21 11:40:50 UTC
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 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.

Comment 47 Ciaran McCreesh 2004-06-21 11:43:56 UTC
We used to do this with redhat's kernels. Best to consult with whoever did the removing to see why it was dropped.
Comment 48 Greg Kroah-Hartman (RETIRED) gentoo-dev 2004-06-21 14:13:29 UTC
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 :)
Comment 49 Tobias Weisserth 2004-06-21 15:21:38 UTC
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.

Comment 50 Konstantin Arkhipov (RETIRED) gentoo-dev 2004-06-22 04:25:32 UTC
Tobias, this is an ebuild for SuSE kernel:

hope, it helps
Comment 51 Tim Yamin (RETIRED) gentoo-dev 2004-06-24 02:47:22 UTC
*** Bug 54992 has been marked as a duplicate of this bug. ***
Comment 52 Haplo 2004-06-30 23:48:40 UTC
* poke *
is there going to be an official patch for the 2.4.26 in portage anytime soonish?
Comment 53 Thierry Carrez (RETIRED) gentoo-dev 2004-07-01 01:03:50 UTC
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.
Comment 54 Tim Yamin (RETIRED) gentoo-dev 2004-07-03 16:05:40 UTC
GLSA 200407-02;; closing as FIXED.