Comment 4 for bug 647071

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

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 <email address hidden>
    [ Rather than add a cast, just make the function take the right type -Linus ]
    Signed-off-by: Linus Torvalds <email address hidden>
    (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 <email address hidden>
    (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 <email address hidden>
    Cc: <email address hidden>
    (cherry picked from commit 1fc8a117865b54590acd773a55fbac9221b018f0)