Bugzilla Bug 53804

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 an attachment (id=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 an attachment (id=33168) [details]
Patch for vanilla 2.4.26 kernels

This patch for signal.c makes the kernels secure against the evil code

Created an attachment (id=33169) [details]
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 an attachment (id=33230) [details]
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]

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.