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.rosenb...@gmail.com>
[ Rather than add a cast, just make the function take the right type -Linus
]
Signed-off-by: Linus Torvalds <torva...@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 <drosenb...@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.bec...@oracle.com>
Cc: sta...@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 Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
