Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel 2.2.13 Makes the Scene

Posted by Hemos on from the rolling-in-the-barrels dept.

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.

2 of 103 comments (clear)

  1. Re:God bless Alan Cox and Linux Torvalds. by GooberToo · · Score: 5

    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.

  2. You really should upgrade by aheitner · · Score: 5

    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 :)