[Bug 647071] Re: 0-day Maverick Kernel Upload

[Leann Ogasawara]

And I've just been notified of 3 more CVE fixes which should be
included:

http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3437.html

    Fix pktcdvd ioctl dev_minor range check
    
    CVE-2010-3437
    
    The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a
    pktcdvd_device from the global pkt_devs array.  The index into this
    array is provided directly by the user and is a signed integer, so
    the comparison to ensure that it falls within the bounds of this 
    array will fail when provided with a negative index.
    
    This can be used to read arbitrary kernel memory or cause a crash
    due to an invalid pointer dereference.  This can be exploited by
    users with permission to open /dev/pktcdvd/control (on many 
    distributions, this is readable by group "cdrom").
    
    Signed-off-by: Dan Rosenberg <dan.j.rosenberg at gmail.com>
    [ Rather than add a cast, just make the function take the right type -Linus ]
    Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
    (cherry picked from commit 252a52aa4fa22a668f019e55b3aac3ff71ec1c29)

=====

http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3705.html

    CVE-2010-3705

    The sctp_asoc_get_hmac() function iterates through a peer's hmac_ids
    array and attempts to ensure that only a supported hmac entry is
    returned.  The current code fails to do this properly - if the last
    id in the array is out of range (greater than 
    SCTP_AUTH_HMAC_ID_MAX), the id integer remains set after exiting the 
    loop, and the address of an out-of-bounds entry will be returned and
    subsequently used in the parent function, causing potentially ugly
    memory corruption.  This patch resets the id integer to 0 on
    encountering an invalid id so that NULL will be returned after
    finishing the loop if no valid ids are found.

    Signed-off-by: Dan Rosenberg <drosenberg at vsecurity.com>
    (cherry-picked from http://marc.info/?l=linux-kernel&m=128596992418814&w=2)

=====

http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-NNN2.html

    ocfs2: Don't walk off the end of fast symlinks.

    CVE-2010-NNN2

    (Official CVE # not yet assigned)

    ocfs2 fast symlinks are NUL terminated strings stored inline in the
    inode data area.  However, disk corruption or a local attacker
    could, in theory, remove that NUL.  Because we're using strlen() (my 
    fault, introduced in a731d1 when removing vfs_follow_link()), we 
    could walk off the end of that string.

    Signed-off-by: Joel Becker <joel.becker at oracle.com>
    Cc: stable at kernel.org
    (cherry picked from commit 1fc8a117865b54590acd773a55fbac9221b018f0)


** CVE added: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2010-3437

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2010-3705

-- 
0-day Maverick Kernel Upload
https://bugs.launchpad.net/bugs/647071
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to linux in ubuntu.