Slashdot Mirror
Linux Kernel 2.2.13 Makes the Scene
Mads-Martin was one of the many folks to point out that 2.2.13 has made the mirrors. The patch is also up on kernel.org. You know the routine - download, compile, etc.
← Back to Stories (view on slashdot.org)
Since Alan Cox have been taking over the 2.2 kernel branch, there's lot of good info about it at www.uk.linux.org and at his diary.
Can we please not post kernel releases unless the change log is also attached? Without this, I fear that we are pushing the "you must upgrade" mentality that MS users are used to. This way, we may also help cut down on the number of downloads that are done and free up some bandwidth for those people that may actually need the fix.
A while ago somebody posted in the gcc 2.95 announcement article that all you had to do to get the kernel compiled fine with 2.95(.1) was add -fno-strict-aliasing to the CFLAGS in the Makefile - it works fine for me, I've been running 2.2.13 compiled with gcc 2.95.1 since a few hours now.
Here's the gcc 2.95 story, it's comment #26.
NCC (Nature's C Compiler) does support the -superstition flag, but this is turned off by default, if you also use -geek. You can override this, by selecting -spooky. However, -spooky cannot be used with any debug flags and will automatically disable any reality exception handlers.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
from 2.2.12 to this kernel.
:)
This is important: there was a nasty stack-smashing bug that was fixed late in the pre-releases for this kernel.
It was discovered by ben at valinux dot com, and was posted to BugTraq on Friday.
Ben writes:
While doing some debugging, I discovered a really nasty stack smash
bug in linux-2.2.12. The I haven't checked previous versions of the
2.2 kernel but bug appears to be fixed in linux-2.2.13pre17.
If I am reading this correctly, the implications of this bug could be
very dire. It may be possible to easily obtain root privilege on any
box running this kernel.
Basically the problem is that the execve system call checks that argv
is a valid pointer but it doesn't check that all of the pointers in
argv array are valid pointers. If you pass bad pointers into the
execve system call you can corrupt the processes stack before it
returns to user space. Then when the kernel hands off the process to
the elf loader code and which begins to setup the processes it can be
made to execute some malicious code in place of the program's main
function.
This is particularly scary because all of this occurs BEFORE the
program begins executing its main function and AFTER the program
returns to user space with privilege. Therefore no matter how well
audited the program may be it can be used as to gain privilege.
The thing that tipped me off to the problem was that a program that I
exec'd was getting killed with SIGSEGV in __libc_start_main before my
main function began running.
-ben
There was more discussion that followed, tho I won't summarize it here. But do upgrade