--- /dev/null
+From e37736777254ce1abc85493a5cacbefe5983b896 Mon Sep 17 00:00:00 2001
+From: "Tu, Xiaobing" <xiaobing.tu@intel.com>
+Date: Tue, 23 Oct 2012 01:03:00 +0200
+Subject: Fix memory leak in cpufreq stats.
+
+From: "Tu, Xiaobing" <xiaobing.tu@intel.com>
+
+commit e37736777254ce1abc85493a5cacbefe5983b896 upstream.
+
+When system enters sleep, non-boot CPUs will be disabled.
+Cpufreq stats sysfs is created when the CPU is up, but it is not
+freed when the CPU is going down. This will cause memory leak.
+
+Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
+Signed-off-by: guifang tang <guifang.tang@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: Colin Cross <ccross@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/cpufreq_stats.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/cpufreq/cpufreq_stats.c
++++ b/drivers/cpufreq/cpufreq_stats.c
+@@ -329,6 +329,7 @@ static int __cpuinit cpufreq_stat_cpu_ca
+ cpufreq_update_policy(cpu);
+ break;
+ case CPU_DOWN_PREPARE:
++ case CPU_DOWN_PREPARE_FROZEN:
+ cpufreq_stats_free_sysfs(cpu);
+ break;
+ case CPU_DEAD:
--- /dev/null
+From 0da9dfdd2cd9889201bc6f6f43580c99165cd087 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Tue, 12 Mar 2013 16:44:31 +1100
+Subject: keys: fix race with concurrent install_user_keyrings()
+
+From: David Howells <dhowells@redhat.com>
+
+commit 0da9dfdd2cd9889201bc6f6f43580c99165cd087 upstream.
+
+This fixes CVE-2013-1792.
+
+There is a race in install_user_keyrings() that can cause a NULL pointer
+dereference when called concurrently for the same user if the uid and
+uid-session keyrings are not yet created. It might be possible for an
+unprivileged user to trigger this by calling keyctl() from userspace in
+parallel immediately after logging in.
+
+Assume that we have two threads both executing lookup_user_key(), both
+looking for KEY_SPEC_USER_SESSION_KEYRING.
+
+ THREAD A THREAD B
+ =============================== ===============================
+ ==>call install_user_keyrings();
+ if (!cred->user->session_keyring)
+ ==>call install_user_keyrings()
+ ...
+ user->uid_keyring = uid_keyring;
+ if (user->uid_keyring)
+ return 0;
+ <==
+ key = cred->user->session_keyring [== NULL]
+ user->session_keyring = session_keyring;
+ atomic_inc(&key->usage); [oops]
+
+At the point thread A dereferences cred->user->session_keyring, thread B
+hasn't updated user->session_keyring yet, but thread A assumes it is
+populated because install_user_keyrings() returned ok.
+
+The race window is really small but can be exploited if, for example,
+thread B is interrupted or preempted after initializing uid_keyring, but
+before doing setting session_keyring.
+
+This couldn't be reproduced on a stock kernel. However, after placing
+systemtap probe on 'user->session_keyring = session_keyring;' that
+introduced some delay, the kernel could be crashed reliably.
+
+Fix this by checking both pointers before deciding whether to return.
+Alternatively, the test could be done away with entirely as it is checked
+inside the mutex - but since the mutex is global, that may not be the best
+way.
+
+Signed-off-by: David Howells <dhowells@redhat.com>
+Reported-by: Mateusz Guzik <mguzik@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: James Morris <james.l.morris@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/keys/process_keys.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/security/keys/process_keys.c
++++ b/security/keys/process_keys.c
+@@ -54,7 +54,7 @@ int install_user_keyrings(void)
+
+ kenter("%p{%u}", user, user->uid);
+
+- if (user->uid_keyring) {
++ if (user->uid_keyring && user->session_keyring) {
+ kleave(" = 0 [exist]");
+ return 0;
+ }
alsa-ice1712-initialize-card-private_data-properly.patch
alsa-vmaster-fix-slave-change-notification.patch
e1000e-fix-pci-device-enable-counter-balance.patch
+keys-fix-race-with-concurrent-install_user_keyrings.patch
+vfs-fix-pipe-counter-breakage.patch
+fix-memory-leak-in-cpufreq-stats.patch
--- /dev/null
+From a930d8790552658140d7d0d2e316af4f0d76a512 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@ZenIV.linux.org.uk>
+Date: Tue, 12 Mar 2013 02:59:49 +0000
+Subject: vfs: fix pipe counter breakage
+
+From: Al Viro <viro@ZenIV.linux.org.uk>
+
+commit a930d8790552658140d7d0d2e316af4f0d76a512 upstream.
+
+If you open a pipe for neither read nor write, the pipe code will not
+add any usage counters to the pipe, causing the 'struct pipe_inode_info"
+to be potentially released early.
+
+That doesn't normally matter, since you cannot actually use the pipe,
+but the pipe release code - particularly fasync handling - still expects
+the actual pipe infrastructure to all be there. And rather than adding
+NULL pointer checks, let's just disallow this case, the same way we
+already do for the named pipe ("fifo") case.
+
+This is ancient going back to pre-2.4 days, and until trinity, nobody
+naver noticed.
+
+Reported-by: Dave Jones <davej@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/pipe.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/pipe.c
++++ b/fs/pipe.c
+@@ -859,6 +859,9 @@ pipe_rdwr_open(struct inode *inode, stru
+ {
+ int ret = -ENOENT;
+
++ if (!(filp->f_mode & (FMODE_READ|FMODE_WRITE)))
++ return -EINVAL;
++
+ mutex_lock(&inode->i_mutex);
+
+ if (inode->i_pipe) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
