Activity log for bug #647071

Date Who What changed Old value New value Message
2010-09-24 18:46:45 Leann Ogasawara bug added bug
2010-09-24 18:51:50 Leann Ogasawara description The Ubuntu Kernel Team would like to propose the following fixes which would warrant a 0-day Maverick kernel upload. All of the fixes are security related in nature: http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3080.html ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open() CVE-2010-3080 The error handling in snd_seq_oss_open() has several bad codes that do dereferecing released pointers and double-free of kmalloc'ed data. The object dp is release in free_devinfo() that is called via private_free callback. The rest shouldn't touch this object any more. The patch changes delete_port() to call kfree() in any case, and gets rid of unnecessary calls of destructors in snd_seq_oss_open(). Reported-and-tested-by: Tavis Ormandy <taviso@cmpxchg8b.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 27f7ad53829f79e799a253285318bff79ece15bd) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring CVE-2010-2960 Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership of the parent process's session keyring whether or not the parent has a session keyring [CVE-2010-2960]. This results in the following oops: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 IP: [<ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443 ... Call Trace: [<ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443 [<ffffffff8109d286>] ? __do_fault+0x24b/0x3d0 [<ffffffff811af98c>] sys_keyctl+0xb4/0xb8 [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b if the parent process has no session keyring. If the system is using pam_keyinit then it mostly protected against this as all processes derived from a login will have inherited the session keyring created by pam_keyinit during the log in procedure. To test this, pam_keyinit calls need to be commented out in /etc/pam.d/. Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Tavis Ormandy <taviso@cmpxchg8b.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html KEYS: Fix RCU no-lock warning in keyctl_session_to_parent() CVE-2010-2960 There's an protected access to the parent process's credentials in the middle of keyctl_session_to_parent(). This results in the following RCU warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by keyctl-session-/2137: #0: (tasklist_lock){.+.+..}, at: [<ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236 stack backtrace: Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1 Call Trace: [<ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236 [<ffffffff811af77e>] sys_keyctl+0xb4/0xb6 [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b The code should take the RCU read lock to make sure the parents credentials don't go away, even though it's holding a spinlock and has IRQ disabled. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 9d1ac65a9698513d00e5608d93fca0c53f536c14) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2955.html wireless extensions: fix kernel heap content leak CVE-2010-2955 Wireless extensions have an unfortunate, undocumented requirement which requires drivers to always fill iwp->length when returning a successful status. When a driver doesn't do this, it leads to a kernel heap content leak when userspace offers a larger buffer than would have been necessary. Arguably, this is a driver bug, as it should, if it returns 0, fill iwp->length, even if it separately indicated that the buffer contents was not valid. However, we can also at least avoid the memory content leak if the driver doesn't do this by setting the iwp length to max_tokens, which then reflects how big the buffer is that the driver may fill, regardless of how big the userspace buffer is. To illustrate the point, this patch also fixes a corresponding cfg80211 bug (since this requirement isn't documented nor was ever pointed out by anyone during code review, I don't trust all drivers nor all cfg80211 handlers to implement it correctly). Cc: stable@kernel.org [all the way back] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> (cherry picked from commit 42da2f948d949efd0111309f5827bf0298bcc9a4) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2954.html irda: Correctly clean up self->ias_obj on irda_bind() failure. CVE-2010-2954 If irda_open_tsap() fails, the irda_bind() code tries to destroy the ->ias_obj object by hand, but does so wrongly. In particular, it fails to a) release the hashbin attached to the object and b) reset the self->ias_obj pointer to NULL. Fix both problems by using irias_delete_object() and explicitly setting self->ias_obj to NULL, just as irda_release() does. Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257) ===== AppArmor: Initialize sa.aad.error within audit_net() sa.aad.error is always 0 and therefore aa_net_perm() will always return 0 (rather than -EACCESS) no matter how "net_allowed_af" is specified. The Ubuntu Kernel Team would like to propose the following fixes which would warrant a 0-day Maverick kernel upload. All of the fixes are security related in nature: http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3080.html     ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()     CVE-2010-3080     The error handling in snd_seq_oss_open() has several bad codes that     do dereferecing released pointers and double-free of kmalloc'ed data. The object dp is release in free_devinfo() that is called via     private_free callback. The rest shouldn't touch this object any more.     The patch changes delete_port() to call kfree() in any case, and gets rid of unnecessary calls of destructors in snd_seq_oss_open().     Reported-and-tested-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Cc: <stable@kernel.org>     Signed-off-by: Takashi Iwai <tiwai@suse.de>     (cherry picked from commit 27f7ad53829f79e799a253285318bff79ece15bd) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring     CVE-2010-2960     Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership of the parent process's session keyring whether or not the parent has a session keyring [CVE-2010-2960].     This results in the following oops:       BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0       IP: [<ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443       ...       Call Trace:        [<ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443        [<ffffffff8109d286>] ? __do_fault+0x24b/0x3d0        [<ffffffff811af98c>] sys_keyctl+0xb4/0xb8        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     if the parent process has no session keyring.     If the system is using pam_keyinit then it mostly protected against this as all processes derived from a login will have inherited the session keyring created by pam_keyinit during the log in procedure.     To test this, pam_keyinit calls need to be commented out in /etc/pam.d/.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David Howells <dhowells@redhat.com>     Acked-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()     CVE-2010-2960     There's an protected access to the parent process's credentials in the middle of keyctl_session_to_parent(). This results in the following RCU warning:       ===================================================       [ INFO: suspicious rcu_dereference_check() usage. ]       ---------------------------------------------------       security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!       other info that might help us debug this:       rcu_scheduler_active = 1, debug_locks = 0       1 lock held by keyctl-session-/2137:        #0: (tasklist_lock){.+.+..}, at: [<ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236       stack backtrace:       Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1       Call Trace:        [<ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3        [<ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236        [<ffffffff811af77e>] sys_keyctl+0xb4/0xb6        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     The code should take the RCU read lock to make sure the parents credentials don't go away, even though it's holding a spinlock and has IRQ disabled.     Signed-off-by: David Howells <dhowells@redhat.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 9d1ac65a9698513d00e5608d93fca0c53f536c14) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2955.html     wireless extensions: fix kernel heap content leak     CVE-2010-2955     Wireless extensions have an unfortunate, undocumented     requirement which requires drivers to always fill     iwp->length when returning a successful status. When     a driver doesn't do this, it leads to a kernel heap     content leak when userspace offers a larger buffer     than would have been necessary.     Arguably, this is a driver bug, as it should, if it     returns 0, fill iwp->length, even if it separately     indicated that the buffer contents was not valid.     However, we can also at least avoid the memory content     leak if the driver doesn't do this by setting the iwp     length to max_tokens, which then reflects how big the     buffer is that the driver may fill, regardless of how     big the userspace buffer is.     To illustrate the point, this patch also fixes a     corresponding cfg80211 bug (since this requirement     isn't documented nor was ever pointed out by anyone     during code review, I don't trust all drivers nor     all cfg80211 handlers to implement it correctly).     Cc: stable@kernel.org [all the way back]     Signed-off-by: Johannes Berg <johannes.berg@intel.com>     Signed-off-by: John W. Linville <linville@tuxdriver.com>     (cherry picked from commit 42da2f948d949efd0111309f5827bf0298bcc9a4) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2954.html     irda: Correctly clean up self->ias_obj on irda_bind() failure.     CVE-2010-2954     If irda_open_tsap() fails, the irda_bind() code tries to destroy     the ->ias_obj object by hand, but does so wrongly.     In particular, it fails to a) release the hashbin attached to the     object and b) reset the self->ias_obj pointer to NULL.     Fix both problems by using irias_delete_object() and explicitly     setting self->ias_obj to NULL, just as irda_release() does.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David S. Miller <davem@davemloft.net>     (cherry picked from commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257) ===== AppArmor: Initialize sa.aad.error within audit_net()     sa.aad.error is always 0 and therefore aa_net_perm() will always return 0 (rather than -EACCESS) no matter how "net_allowed_af" is specified.
2010-09-24 18:54:00 Leann Ogasawara nominated for series Ubuntu Maverick
2010-09-24 18:54:00 Leann Ogasawara bug task added linux (Ubuntu Maverick)
2010-09-24 18:54:15 Leann Ogasawara linux (Ubuntu Maverick): milestone maverick-updates
2010-09-24 18:57:55 Leann Ogasawara description The Ubuntu Kernel Team would like to propose the following fixes which would warrant a 0-day Maverick kernel upload. All of the fixes are security related in nature: http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3080.html     ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()     CVE-2010-3080     The error handling in snd_seq_oss_open() has several bad codes that     do dereferecing released pointers and double-free of kmalloc'ed data. The object dp is release in free_devinfo() that is called via     private_free callback. The rest shouldn't touch this object any more.     The patch changes delete_port() to call kfree() in any case, and gets rid of unnecessary calls of destructors in snd_seq_oss_open().     Reported-and-tested-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Cc: <stable@kernel.org>     Signed-off-by: Takashi Iwai <tiwai@suse.de>     (cherry picked from commit 27f7ad53829f79e799a253285318bff79ece15bd) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring     CVE-2010-2960     Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership of the parent process's session keyring whether or not the parent has a session keyring [CVE-2010-2960].     This results in the following oops:       BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0       IP: [<ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443       ...       Call Trace:        [<ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443        [<ffffffff8109d286>] ? __do_fault+0x24b/0x3d0        [<ffffffff811af98c>] sys_keyctl+0xb4/0xb8        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     if the parent process has no session keyring.     If the system is using pam_keyinit then it mostly protected against this as all processes derived from a login will have inherited the session keyring created by pam_keyinit during the log in procedure.     To test this, pam_keyinit calls need to be commented out in /etc/pam.d/.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David Howells <dhowells@redhat.com>     Acked-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()     CVE-2010-2960     There's an protected access to the parent process's credentials in the middle of keyctl_session_to_parent(). This results in the following RCU warning:       ===================================================       [ INFO: suspicious rcu_dereference_check() usage. ]       ---------------------------------------------------       security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!       other info that might help us debug this:       rcu_scheduler_active = 1, debug_locks = 0       1 lock held by keyctl-session-/2137:        #0: (tasklist_lock){.+.+..}, at: [<ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236       stack backtrace:       Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1       Call Trace:        [<ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3        [<ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236        [<ffffffff811af77e>] sys_keyctl+0xb4/0xb6        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     The code should take the RCU read lock to make sure the parents credentials don't go away, even though it's holding a spinlock and has IRQ disabled.     Signed-off-by: David Howells <dhowells@redhat.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 9d1ac65a9698513d00e5608d93fca0c53f536c14) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2955.html     wireless extensions: fix kernel heap content leak     CVE-2010-2955     Wireless extensions have an unfortunate, undocumented     requirement which requires drivers to always fill     iwp->length when returning a successful status. When     a driver doesn't do this, it leads to a kernel heap     content leak when userspace offers a larger buffer     than would have been necessary.     Arguably, this is a driver bug, as it should, if it     returns 0, fill iwp->length, even if it separately     indicated that the buffer contents was not valid.     However, we can also at least avoid the memory content     leak if the driver doesn't do this by setting the iwp     length to max_tokens, which then reflects how big the     buffer is that the driver may fill, regardless of how     big the userspace buffer is.     To illustrate the point, this patch also fixes a     corresponding cfg80211 bug (since this requirement     isn't documented nor was ever pointed out by anyone     during code review, I don't trust all drivers nor     all cfg80211 handlers to implement it correctly).     Cc: stable@kernel.org [all the way back]     Signed-off-by: Johannes Berg <johannes.berg@intel.com>     Signed-off-by: John W. Linville <linville@tuxdriver.com>     (cherry picked from commit 42da2f948d949efd0111309f5827bf0298bcc9a4) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2954.html     irda: Correctly clean up self->ias_obj on irda_bind() failure.     CVE-2010-2954     If irda_open_tsap() fails, the irda_bind() code tries to destroy     the ->ias_obj object by hand, but does so wrongly.     In particular, it fails to a) release the hashbin attached to the     object and b) reset the self->ias_obj pointer to NULL.     Fix both problems by using irias_delete_object() and explicitly     setting self->ias_obj to NULL, just as irda_release() does.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David S. Miller <davem@davemloft.net>     (cherry picked from commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257) ===== AppArmor: Initialize sa.aad.error within audit_net()     sa.aad.error is always 0 and therefore aa_net_perm() will always return 0 (rather than -EACCESS) no matter how "net_allowed_af" is specified. The Ubuntu Kernel Team would like to propose the following fixes which would warrant a 0-day Maverick kernel upload. All of the fixes are security related in nature: http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3080.html     ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()     CVE-2010-3080     The error handling in snd_seq_oss_open() has several bad codes that     do dereferecing released pointers and double-free of kmalloc'ed     data. The object dp is release in free_devinfo() that is called via     private_free callback. The rest shouldn't touch this object any     more.     The patch changes delete_port() to call kfree() in any case, and     gets rid of unnecessary calls of destructors in snd_seq_oss_open().     Reported-and-tested-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Cc: <stable@kernel.org>     Signed-off-by: Takashi Iwai <tiwai@suse.de>     (cherry picked from commit 27f7ad53829f79e799a253285318bff79ece15bd) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix bug in keyctl_session_to_parent() if parent has no session           keyring     CVE-2010-2960     Fix a bug in keyctl_session_to_parent() whereby it tries to check     the ownership of the parent process's session keyring whether or     not the parent has a session keyring [CVE-2010-2960].     This results in the following oops:       BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0       IP: [<ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443       ...       Call Trace:        [<ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443        [<ffffffff8109d286>] ? __do_fault+0x24b/0x3d0        [<ffffffff811af98c>] sys_keyctl+0xb4/0xb8        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     if the parent process has no session keyring.     If the system is using pam_keyinit then it mostly protected against     this as all processes derived from a login will have inherited the     session keyring created by pam_keyinit during the log in procedure.     To test this, pam_keyinit calls need to be commented out in     /etc/pam.d/.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David Howells <dhowells@redhat.com>     Acked-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()     CVE-2010-2960     There's an protected access to the parent process's credentials in     the middle of keyctl_session_to_parent(). This results in the     following RCU warning:       ===================================================       [ INFO: suspicious rcu_dereference_check() usage. ]       ---------------------------------------------------       security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!       other info that might help us debug this:       rcu_scheduler_active = 1, debug_locks = 0       1 lock held by keyctl-session-/2137:        #0: (tasklist_lock){.+.+..}, at: [<ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236       stack backtrace:       Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1       Call Trace:        [<ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3        [<ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236        [<ffffffff811af77e>] sys_keyctl+0xb4/0xb6        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     The code should take the RCU read lock to make sure the parents     credentials don't go away, even though it's holding a spinlock     and has IRQ disabled.     Signed-off-by: David Howells <dhowells@redhat.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 9d1ac65a9698513d00e5608d93fca0c53f536c14) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2955.html     wireless extensions: fix kernel heap content leak     CVE-2010-2955     Wireless extensions have an unfortunate, undocumented     requirement which requires drivers to always fill     iwp->length when returning a successful status. When     a driver doesn't do this, it leads to a kernel heap     content leak when userspace offers a larger buffer     than would have been necessary.     Arguably, this is a driver bug, as it should, if it     returns 0, fill iwp->length, even if it separately     indicated that the buffer contents was not valid.     However, we can also at least avoid the memory content     leak if the driver doesn't do this by setting the iwp     length to max_tokens, which then reflects how big the     buffer is that the driver may fill, regardless of how     big the userspace buffer is.     To illustrate the point, this patch also fixes a     corresponding cfg80211 bug (since this requirement     isn't documented nor was ever pointed out by anyone     during code review, I don't trust all drivers nor     all cfg80211 handlers to implement it correctly).     Cc: stable@kernel.org [all the way back]     Signed-off-by: Johannes Berg <johannes.berg@intel.com>     Signed-off-by: John W. Linville <linville@tuxdriver.com>     (cherry picked from commit 42da2f948d949efd0111309f5827bf0298bcc9a4) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2954.html     irda: Correctly clean up self->ias_obj on irda_bind() failure.     CVE-2010-2954     If irda_open_tsap() fails, the irda_bind() code tries to destroy     the ->ias_obj object by hand, but does so wrongly.     In particular, it fails to a) release the hashbin attached to the     object and b) reset the self->ias_obj pointer to NULL.     Fix both problems by using irias_delete_object() and explicitly     setting self->ias_obj to NULL, just as irda_release() does.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David S. Miller <davem@davemloft.net>     (cherry picked from commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257) ===== https://lists.ubuntu.com/archives/kernel-team/2010-September/012894.html AppArmor: Initialize sa.aad.error within audit_net()     sa.aad.error is always 0 and therefore aa_net_perm() will always     return 0 (rather than -EACCESS) no matter how "net_allowed_af"     is specified.
2010-09-24 19:02:22 Leann Ogasawara linux (Ubuntu Maverick): importance Undecided High
2010-09-24 19:02:22 Leann Ogasawara linux (Ubuntu Maverick): status New Triaged
2010-09-24 19:02:22 Leann Ogasawara linux (Ubuntu Maverick): milestone maverick-updates
2010-09-24 19:02:22 Leann Ogasawara linux (Ubuntu Maverick): assignee Canonical Kernel Team (canonical-kernel-team)
2010-09-24 19:05:31 Leann Ogasawara bug added subscriber Kate Stewart
2010-09-24 19:06:11 Leann Ogasawara bug added subscriber Ubuntu Release Team
2010-09-24 19:28:38 Kate Stewart linux (Ubuntu Maverick): milestone maverick-updates
2010-09-25 10:04:11 Gary M bug added subscriber Gary M
2010-09-27 22:14:37 Robbie Williamson linux (Ubuntu Maverick): status Triaged Confirmed
2010-09-30 20:07:53 e-frog bug added subscriber e-frog
2010-10-01 03:05:07 Nandan Vaidya bug added subscriber Nandan Vaidya
2010-10-05 16:41:19 Leann Ogasawara cve linked 2010-2962
2010-10-06 17:55:58 Leann Ogasawara cve linked 2010-3437
2010-10-06 17:55:58 Leann Ogasawara cve linked 2010-3705
2010-10-06 18:02:45 Leann Ogasawara description The Ubuntu Kernel Team would like to propose the following fixes which would warrant a 0-day Maverick kernel upload. All of the fixes are security related in nature: http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3080.html     ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()     CVE-2010-3080     The error handling in snd_seq_oss_open() has several bad codes that     do dereferecing released pointers and double-free of kmalloc'ed     data. The object dp is release in free_devinfo() that is called via     private_free callback. The rest shouldn't touch this object any     more.     The patch changes delete_port() to call kfree() in any case, and     gets rid of unnecessary calls of destructors in snd_seq_oss_open().     Reported-and-tested-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Cc: <stable@kernel.org>     Signed-off-by: Takashi Iwai <tiwai@suse.de>     (cherry picked from commit 27f7ad53829f79e799a253285318bff79ece15bd) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix bug in keyctl_session_to_parent() if parent has no session           keyring     CVE-2010-2960     Fix a bug in keyctl_session_to_parent() whereby it tries to check     the ownership of the parent process's session keyring whether or     not the parent has a session keyring [CVE-2010-2960].     This results in the following oops:       BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0       IP: [<ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443       ...       Call Trace:        [<ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443        [<ffffffff8109d286>] ? __do_fault+0x24b/0x3d0        [<ffffffff811af98c>] sys_keyctl+0xb4/0xb8        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     if the parent process has no session keyring.     If the system is using pam_keyinit then it mostly protected against     this as all processes derived from a login will have inherited the     session keyring created by pam_keyinit during the log in procedure.     To test this, pam_keyinit calls need to be commented out in     /etc/pam.d/.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David Howells <dhowells@redhat.com>     Acked-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()     CVE-2010-2960     There's an protected access to the parent process's credentials in     the middle of keyctl_session_to_parent(). This results in the     following RCU warning:       ===================================================       [ INFO: suspicious rcu_dereference_check() usage. ]       ---------------------------------------------------       security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!       other info that might help us debug this:       rcu_scheduler_active = 1, debug_locks = 0       1 lock held by keyctl-session-/2137:        #0: (tasklist_lock){.+.+..}, at: [<ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236       stack backtrace:       Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1       Call Trace:        [<ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3        [<ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236        [<ffffffff811af77e>] sys_keyctl+0xb4/0xb6        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     The code should take the RCU read lock to make sure the parents     credentials don't go away, even though it's holding a spinlock     and has IRQ disabled.     Signed-off-by: David Howells <dhowells@redhat.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 9d1ac65a9698513d00e5608d93fca0c53f536c14) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2955.html     wireless extensions: fix kernel heap content leak     CVE-2010-2955     Wireless extensions have an unfortunate, undocumented     requirement which requires drivers to always fill     iwp->length when returning a successful status. When     a driver doesn't do this, it leads to a kernel heap     content leak when userspace offers a larger buffer     than would have been necessary.     Arguably, this is a driver bug, as it should, if it     returns 0, fill iwp->length, even if it separately     indicated that the buffer contents was not valid.     However, we can also at least avoid the memory content     leak if the driver doesn't do this by setting the iwp     length to max_tokens, which then reflects how big the     buffer is that the driver may fill, regardless of how     big the userspace buffer is.     To illustrate the point, this patch also fixes a     corresponding cfg80211 bug (since this requirement     isn't documented nor was ever pointed out by anyone     during code review, I don't trust all drivers nor     all cfg80211 handlers to implement it correctly).     Cc: stable@kernel.org [all the way back]     Signed-off-by: Johannes Berg <johannes.berg@intel.com>     Signed-off-by: John W. Linville <linville@tuxdriver.com>     (cherry picked from commit 42da2f948d949efd0111309f5827bf0298bcc9a4) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2954.html     irda: Correctly clean up self->ias_obj on irda_bind() failure.     CVE-2010-2954     If irda_open_tsap() fails, the irda_bind() code tries to destroy     the ->ias_obj object by hand, but does so wrongly.     In particular, it fails to a) release the hashbin attached to the     object and b) reset the self->ias_obj pointer to NULL.     Fix both problems by using irias_delete_object() and explicitly     setting self->ias_obj to NULL, just as irda_release() does.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David S. Miller <davem@davemloft.net>     (cherry picked from commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257) ===== https://lists.ubuntu.com/archives/kernel-team/2010-September/012894.html AppArmor: Initialize sa.aad.error within audit_net()     sa.aad.error is always 0 and therefore aa_net_perm() will always     return 0 (rather than -EACCESS) no matter how "net_allowed_af"     is specified. The Ubuntu Kernel Team would like to propose the following fixes which would warrant a 0-day Maverick kernel upload. All of the fixes are security related in nature: http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3080.html     ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()     CVE-2010-3080     The error handling in snd_seq_oss_open() has several bad codes that     do dereferecing released pointers and double-free of kmalloc'ed     data. The object dp is release in free_devinfo() that is called via     private_free callback. The rest shouldn't touch this object any     more.     The patch changes delete_port() to call kfree() in any case, and     gets rid of unnecessary calls of destructors in snd_seq_oss_open().     Reported-and-tested-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Cc: <stable@kernel.org>     Signed-off-by: Takashi Iwai <tiwai@suse.de>     (cherry picked from commit 27f7ad53829f79e799a253285318bff79ece15bd) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix bug in keyctl_session_to_parent() if parent has no session           keyring     CVE-2010-2960     Fix a bug in keyctl_session_to_parent() whereby it tries to check     the ownership of the parent process's session keyring whether or     not the parent has a session keyring [CVE-2010-2960].     This results in the following oops:       BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0       IP: [<ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443       ...       Call Trace:        [<ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443        [<ffffffff8109d286>] ? __do_fault+0x24b/0x3d0        [<ffffffff811af98c>] sys_keyctl+0xb4/0xb8        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     if the parent process has no session keyring.     If the system is using pam_keyinit then it mostly protected against     this as all processes derived from a login will have inherited the     session keyring created by pam_keyinit during the log in procedure.     To test this, pam_keyinit calls need to be commented out in     /etc/pam.d/.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David Howells <dhowells@redhat.com>     Acked-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2960.html     KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()     CVE-2010-2960     There's an protected access to the parent process's credentials in     the middle of keyctl_session_to_parent(). This results in the     following RCU warning:       ===================================================       [ INFO: suspicious rcu_dereference_check() usage. ]       ---------------------------------------------------       security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!       other info that might help us debug this:       rcu_scheduler_active = 1, debug_locks = 0       1 lock held by keyctl-session-/2137:        #0: (tasklist_lock){.+.+..}, at: [<ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236       stack backtrace:       Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1       Call Trace:        [<ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3        [<ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236        [<ffffffff811af77e>] sys_keyctl+0xb4/0xb6        [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b     The code should take the RCU read lock to make sure the parents     credentials don't go away, even though it's holding a spinlock     and has IRQ disabled.     Signed-off-by: David Howells <dhowells@redhat.com>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>     (cherry picked from commit 9d1ac65a9698513d00e5608d93fca0c53f536c14) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2955.html     wireless extensions: fix kernel heap content leak     CVE-2010-2955     Wireless extensions have an unfortunate, undocumented     requirement which requires drivers to always fill     iwp->length when returning a successful status. When     a driver doesn't do this, it leads to a kernel heap     content leak when userspace offers a larger buffer     than would have been necessary.     Arguably, this is a driver bug, as it should, if it     returns 0, fill iwp->length, even if it separately     indicated that the buffer contents was not valid.     However, we can also at least avoid the memory content     leak if the driver doesn't do this by setting the iwp     length to max_tokens, which then reflects how big the     buffer is that the driver may fill, regardless of how     big the userspace buffer is.     To illustrate the point, this patch also fixes a     corresponding cfg80211 bug (since this requirement     isn't documented nor was ever pointed out by anyone     during code review, I don't trust all drivers nor     all cfg80211 handlers to implement it correctly).     Cc: stable@kernel.org [all the way back]     Signed-off-by: Johannes Berg <johannes.berg@intel.com>     Signed-off-by: John W. Linville <linville@tuxdriver.com>     (cherry picked from commit 42da2f948d949efd0111309f5827bf0298bcc9a4) ===== http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-2954.html     irda: Correctly clean up self->ias_obj on irda_bind() failure.     CVE-2010-2954     If irda_open_tsap() fails, the irda_bind() code tries to destroy     the ->ias_obj object by hand, but does so wrongly.     In particular, it fails to a) release the hashbin attached to the     object and b) reset the self->ias_obj pointer to NULL.     Fix both problems by using irias_delete_object() and explicitly     setting self->ias_obj to NULL, just as irda_release() does.     Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>     Signed-off-by: David S. Miller <davem@davemloft.net>     (cherry picked from commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257) ===== https://lists.ubuntu.com/archives/kernel-team/2010-September/012894.html AppArmor: Initialize sa.aad.error within audit_net()     sa.aad.error is always 0 and therefore aa_net_perm() will always     return 0 (rather than -EACCESS) no matter how "net_allowed_af"     is specified. ===== http://launchpad.net/bugs/634702 intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang When the Lenovo Ideapad S10-3 is booted with HT enabled, it hits a boot hang in the intel_idle driver. This occurs when entering ATM-C4 for the first time, unless BM_STS is first cleared. acpi_idle doesn't see this because it first checks and clears BM_STS, but it would hit the same hang if that check were disabled. http://bugs.meego.com/show_bug.cgi?id=7093 BugLink: http://launchpad.net/bugs/634702 Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Ike Panhc <ike.pan@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com> ===== http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2962 drm/i915: Rephrase pwrite bounds checking to avoid any potential overflow CVE-2010-2962 ... and do the same for pread. ===== http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2962 drm/i915: Skip pread/pwrite if size to copy is 0. CVE-2010-2962 ===== http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2962 drm/i915: Sanity check pread/pwrite CVE-2010-2962 Move the access control up from the fast paths which are no longer universally taken first up into the caller. This then duplicates some sanity checking along the slow paths, but is much simpler. ===== 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@gmail.com> [ Rather than add a cast, just make the function take the right type -Linus ] Signed-off-by: Linus Torvalds <torvalds@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@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@oracle.com> Cc: stable@kernel.org (cherry picked from commit 1fc8a117865b54590acd773a55fbac9221b018f0)
2010-10-10 08:08:20 Martin Pitt bug added subscriber Ubuntu Security Team
2010-10-10 08:08:28 Martin Pitt security vulnerability no yes
2010-10-10 09:25:35 Martin Pitt linux (Ubuntu Maverick): status Confirmed Fix Committed
2010-10-10 09:25:38 Martin Pitt bug added subscriber Ubuntu Stable Release Updates Team
2010-10-10 09:25:40 Martin Pitt bug added subscriber SRU Verification
2010-10-10 09:25:43 Martin Pitt tags verification-needed
2010-10-11 06:18:31 Gary M linux (Ubuntu Maverick): status Fix Committed Fix Released
2010-10-11 06:28:33 Martin Pitt linux (Ubuntu Maverick): status Fix Released Fix Committed
2010-10-12 07:17:47 Launchpad Janitor linux (Ubuntu Maverick): status Fix Committed Fix Released
2010-10-12 07:17:47 Launchpad Janitor cve linked 2010-2954
2010-10-12 07:17:47 Launchpad Janitor cve linked 2010-2955
2010-10-12 07:17:47 Launchpad Janitor cve linked 2010-2960
2010-10-12 07:17:47 Launchpad Janitor cve linked 2010-3080
2010-10-12 07:19:56 Martin Pitt linux (Ubuntu): status Fix Committed Fix Released
2010-10-12 07:19:56 Martin Pitt linux (Ubuntu): milestone maverick-updates
2010-10-16 06:58:22 Launchpad Janitor branch linked lp:ubuntu/lucid-proposed/linux-lts-backport-maverick