[Bug 647071] Re: 0-day Maverick Kernel Upload
Leann Ogasawara
leann.ogasawara at canonical.com
Fri Sep 24 18:51:50 UTC 2010
** Description changed:
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()
+ ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()
- CVE-2010-3080
+ 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 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().
+ 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 at cmpxchg8b.com>
- Cc: <stable at kernel.org>
- Signed-off-by: Takashi Iwai <tiwai at suse.de>
- (cherry picked from commit 27f7ad53829f79e799a253285318bff79ece15bd)
+ Reported-and-tested-by: Tavis Ormandy <taviso at cmpxchg8b.com>
+ Cc: <stable at kernel.org>
+ Signed-off-by: Takashi Iwai <tiwai at 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
+ KEYS: Fix bug in keyctl_session_to_parent() if parent has no session
+ keyring
- CVE-2010-2960
+ 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].
+ 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:
+ 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
+ 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 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.
+ 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/.
+ To test this, pam_keyinit calls need to be commented out in
+ /etc/pam.d/.
- Reported-by: Tavis Ormandy <taviso at cmpxchg8b.com>
- Signed-off-by: David Howells <dhowells at redhat.com>
- Acked-by: Tavis Ormandy <taviso at cmpxchg8b.com>
- Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
- (cherry picked from commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376)
+ Reported-by: Tavis Ormandy <taviso at cmpxchg8b.com>
+ Signed-off-by: David Howells <dhowells at redhat.com>
+ Acked-by: Tavis Ormandy <taviso at cmpxchg8b.com>
+ Signed-off-by: Linus Torvalds <torvalds at 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()
+ KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()
- CVE-2010-2960
+ 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:
+ 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!
+ ===================================================
+ [ 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:
+ 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
+ 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
+ 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.
+ 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 at redhat.com>
- Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
- (cherry picked from commit 9d1ac65a9698513d00e5608d93fca0c53f536c14)
+ Signed-off-by: David Howells <dhowells at redhat.com>
+ Signed-off-by: Linus Torvalds <torvalds at 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
+ wireless extensions: fix kernel heap content leak
- CVE-2010-2955
+ 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.
+ 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.
+ 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.
+ 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).
+ 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 at kernel.org [all the way back]
- Signed-off-by: Johannes Berg <johannes.berg at intel.com>
- Signed-off-by: John W. Linville <linville at tuxdriver.com>
- (cherry picked from commit 42da2f948d949efd0111309f5827bf0298bcc9a4)
+ Cc: stable at kernel.org [all the way back]
+ Signed-off-by: Johannes Berg <johannes.berg at intel.com>
+ Signed-off-by: John W. Linville <linville at 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.
+ irda: Correctly clean up self->ias_obj on irda_bind() failure.
- CVE-2010-2954
+ 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.
+ 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.
+ 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.
+ 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 at cmpxchg8b.com>
- Signed-off-by: David S. Miller <davem at davemloft.net>
- (cherry picked from commit 628e300cccaa628d8fb92aa28cb7530a3d5f2257)
+ Reported-by: Tavis Ormandy <taviso at cmpxchg8b.com>
+ Signed-off-by: David S. Miller <davem at 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.
+ 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.
** Also affects: linux (Ubuntu Maverick)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Maverick)
Milestone: None => maverick-updates
** Description changed:
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
+ 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.
+ 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().
+ gets rid of unnecessary calls of destructors in snd_seq_oss_open().
Reported-and-tested-by: Tavis Ormandy <taviso at cmpxchg8b.com>
Cc: <stable at kernel.org>
Signed-off-by: Takashi Iwai <tiwai at 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
+ 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].
+ 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.
+ 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/.
+ /etc/pam.d/.
Reported-by: Tavis Ormandy <taviso at cmpxchg8b.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Acked-by: Tavis Ormandy <taviso at cmpxchg8b.com>
Signed-off-by: Linus Torvalds <torvalds at 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:
+ 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.
+ credentials don't go away, even though it's holding a spinlock
+ and has IRQ disabled.
Signed-off-by: David Howells <dhowells at redhat.com>
Signed-off-by: Linus Torvalds <torvalds at 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 at kernel.org [all the way back]
Signed-off-by: Johannes Berg <johannes.berg at intel.com>
Signed-off-by: John W. Linville <linville at 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 at cmpxchg8b.com>
Signed-off-by: David S. Miller <davem at 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.
+ return 0 (rather than -EACCESS) no matter how "net_allowed_af"
+ is specified.
** Changed in: linux (Ubuntu Maverick)
Importance: Undecided => High
** Changed in: linux (Ubuntu Maverick)
Status: New => Triaged
** Changed in: linux (Ubuntu Maverick)
Milestone: maverick-updates => None
** Changed in: linux (Ubuntu Maverick)
Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)
--
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.
More information about the kernel-bugs
mailing list