From: Greg Kroah-Hartman Date: Tue, 12 Mar 2013 20:44:44 +0000 (-0700) Subject: 3.0-stable patches X-Git-Tag: v3.8.3~17 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1eed15c180c27744d71d5d388e5227846821841a;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0-stable patches added patches: fix-memory-leak-in-cpufreq-stats.patch keys-fix-race-with-concurrent-install_user_keyrings.patch vfs-fix-pipe-counter-breakage.patch --- diff --git a/queue-3.0/fix-memory-leak-in-cpufreq-stats.patch b/queue-3.0/fix-memory-leak-in-cpufreq-stats.patch new file mode 100644 index 00000000000..33e124b9ce6 --- /dev/null +++ b/queue-3.0/fix-memory-leak-in-cpufreq-stats.patch @@ -0,0 +1,33 @@ +From e37736777254ce1abc85493a5cacbefe5983b896 Mon Sep 17 00:00:00 2001 +From: "Tu, Xiaobing" +Date: Tue, 23 Oct 2012 01:03:00 +0200 +Subject: Fix memory leak in cpufreq stats. + +From: "Tu, Xiaobing" + +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 +Signed-off-by: guifang tang +Signed-off-by: Rafael J. Wysocki +Cc: Colin Cross +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-3.0/keys-fix-race-with-concurrent-install_user_keyrings.patch b/queue-3.0/keys-fix-race-with-concurrent-install_user_keyrings.patch new file mode 100644 index 00000000000..580386526ed --- /dev/null +++ b/queue-3.0/keys-fix-race-with-concurrent-install_user_keyrings.patch @@ -0,0 +1,72 @@ +From 0da9dfdd2cd9889201bc6f6f43580c99165cd087 Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Tue, 12 Mar 2013 16:44:31 +1100 +Subject: keys: fix race with concurrent install_user_keyrings() + +From: David Howells + +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 +Reported-by: Mateusz Guzik +Signed-off-by: Andrew Morton +Signed-off-by: James Morris +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-3.0/series b/queue-3.0/series index 77da57b3236..526c1be44af 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -13,3 +13,6 @@ drm-radeon-add-primary-dac-adj-quirk-for-r200-board.patch 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 diff --git a/queue-3.0/vfs-fix-pipe-counter-breakage.patch b/queue-3.0/vfs-fix-pipe-counter-breakage.patch new file mode 100644 index 00000000000..cbca1bf50bc --- /dev/null +++ b/queue-3.0/vfs-fix-pipe-counter-breakage.patch @@ -0,0 +1,42 @@ +From a930d8790552658140d7d0d2e316af4f0d76a512 Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Tue, 12 Mar 2013 02:59:49 +0000 +Subject: vfs: fix pipe counter breakage + +From: Al Viro + +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 +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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) {