--- /dev/null
+From 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Date: Mon, 25 Feb 2013 10:20:36 -0500
+Subject: Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
+
+From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+
+commit 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 upstream.
+
+Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
+compat_process_vm_rw() shows that the compatibility code requires an
+explicit "access_ok()" check before calling
+compat_rw_copy_check_uvector(). The same difference seems to appear when
+we compare fs/read_write.c:do_readv_writev() to
+fs/compat.c:compat_do_readv_writev().
+
+This subtle difference between the compat and non-compat requirements
+should probably be debated, as it seems to be error-prone. In fact,
+there are two others sites that use this function in the Linux kernel,
+and they both seem to get it wrong:
+
+Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
+also ends up calling compat_rw_copy_check_uvector() through
+aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
+be missing. Same situation for
+security/keys/compat.c:compat_keyctl_instantiate_key_iov().
+
+I propose that we add the access_ok() check directly into
+compat_rw_copy_check_uvector(), so callers don't have to worry about it,
+and it therefore makes the compat call code similar to its non-compat
+counterpart. Place the access_ok() check in the same location where
+copy_from_user() can trigger a -EFAULT error in the non-compat code, so
+the ABI behaviors are alike on both compat and non-compat.
+
+While we are here, fix compat_do_readv_writev() so it checks for
+compat_rw_copy_check_uvector() negative return values.
+
+And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
+handling.
+
+Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
+Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
+Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/compat.c | 15 +++++++--------
+ mm/process_vm_access.c | 8 --------
+ security/keys/compat.c | 4 ++--
+ 3 files changed, 9 insertions(+), 18 deletions(-)
+
+--- a/fs/compat.c
++++ b/fs/compat.c
+@@ -558,6 +558,10 @@ ssize_t compat_rw_copy_check_uvector(int
+ }
+ *ret_pointer = iov;
+
++ ret = -EFAULT;
++ if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector)))
++ goto out;
++
+ /*
+ * Single unix specification:
+ * We should -EINVAL if an element length is not >= 0 and fitting an
+@@ -1089,17 +1093,12 @@ static ssize_t compat_do_readv_writev(in
+ if (!file->f_op)
+ goto out;
+
+- ret = -EFAULT;
+- if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector)))
+- goto out;
+-
+- tot_len = compat_rw_copy_check_uvector(type, uvector, nr_segs,
++ ret = compat_rw_copy_check_uvector(type, uvector, nr_segs,
+ UIO_FASTIOV, iovstack, &iov, 1);
+- if (tot_len == 0) {
+- ret = 0;
++ if (ret <= 0)
+ goto out;
+- }
+
++ tot_len = ret;
+ ret = rw_verify_area(type, file, pos, tot_len);
+ if (ret < 0)
+ goto out;
+--- a/mm/process_vm_access.c
++++ b/mm/process_vm_access.c
+@@ -429,12 +429,6 @@ compat_process_vm_rw(compat_pid_t pid,
+ if (flags != 0)
+ return -EINVAL;
+
+- if (!access_ok(VERIFY_READ, lvec, liovcnt * sizeof(*lvec)))
+- goto out;
+-
+- if (!access_ok(VERIFY_READ, rvec, riovcnt * sizeof(*rvec)))
+- goto out;
+-
+ if (vm_write)
+ rc = compat_rw_copy_check_uvector(WRITE, lvec, liovcnt,
+ UIO_FASTIOV, iovstack_l,
+@@ -459,8 +453,6 @@ free_iovecs:
+ kfree(iov_r);
+ if (iov_l != iovstack_l)
+ kfree(iov_l);
+-
+-out:
+ return rc;
+ }
+
+--- a/security/keys/compat.c
++++ b/security/keys/compat.c
+@@ -40,12 +40,12 @@ long compat_keyctl_instantiate_key_iov(
+ ARRAY_SIZE(iovstack),
+ iovstack, &iov, 1);
+ if (ret < 0)
+- return ret;
++ goto err;
+ if (ret == 0)
+ goto no_payload_free;
+
+ ret = keyctl_instantiate_key_common(id, iov, ioc, ret, ringid);
+-
++err:
+ if (iov != iovstack)
+ kfree(iov);
+ return ret;
--- /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
+@@ -328,6 +328,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;
+ }
--- /dev/null
+From 89c58c198b252f2bc20657fdd72a2aea788c435c Mon Sep 17 00:00:00 2001
+From: Andrew Lunn <andrew@lunn.ch>
+Date: Sun, 3 Feb 2013 12:32:06 +0100
+Subject: rtc: rtc-mv: Add support for clk to avoid lockups
+
+From: Andrew Lunn <andrew@lunn.ch>
+
+commit 89c58c198b252f2bc20657fdd72a2aea788c435c upstream.
+
+The Marvell RTC on Kirkwood makes use of the runit clock. Ensure the
+driver clk_prepare_enable() this clock, otherwise there is a danger
+the SoC will lockup when accessing RTC registers with the clock
+disabled.
+
+Reported-by: Simon Baatz <gmbnomis@gmail.com>
+Signed-off-by: Andrew Lunn <andrew@lunn.ch>
+Tested-by: Simon Baatz <gmbnomis@gmail.com>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/kirkwood.dtsi | 1 +
+ drivers/rtc/rtc-mv.c | 28 ++++++++++++++++++++++++----
+ 2 files changed, 25 insertions(+), 4 deletions(-)
+
+--- a/arch/arm/boot/dts/kirkwood.dtsi
++++ b/arch/arm/boot/dts/kirkwood.dtsi
+@@ -31,6 +31,7 @@
+ compatible = "mrvl,kirkwood-rtc", "mrvl,orion-rtc";
+ reg = <0x10300 0x20>;
+ interrupts = <53>;
++ clocks = <&gate_clk 7>;
+ };
+ };
+ };
+--- a/drivers/rtc/rtc-mv.c
++++ b/drivers/rtc/rtc-mv.c
+@@ -14,6 +14,7 @@
+ #include <linux/platform_device.h>
+ #include <linux/of.h>
+ #include <linux/delay.h>
++#include <linux/clk.h>
+ #include <linux/gfp.h>
+ #include <linux/module.h>
+
+@@ -41,6 +42,7 @@ struct rtc_plat_data {
+ struct rtc_device *rtc;
+ void __iomem *ioaddr;
+ int irq;
++ struct clk *clk;
+ };
+
+ static int mv_rtc_set_time(struct device *dev, struct rtc_time *tm)
+@@ -221,6 +223,7 @@ static int __devinit mv_rtc_probe(struct
+ struct rtc_plat_data *pdata;
+ resource_size_t size;
+ u32 rtc_time;
++ int ret = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+@@ -239,11 +242,17 @@ static int __devinit mv_rtc_probe(struct
+ if (!pdata->ioaddr)
+ return -ENOMEM;
+
++ pdata->clk = devm_clk_get(&pdev->dev, NULL);
++ /* Not all SoCs require a clock.*/
++ if (!IS_ERR(pdata->clk))
++ clk_prepare_enable(pdata->clk);
++
+ /* make sure the 24 hours mode is enabled */
+ rtc_time = readl(pdata->ioaddr + RTC_TIME_REG_OFFS);
+ if (rtc_time & RTC_HOURS_12H_MODE) {
+ dev_err(&pdev->dev, "24 Hours mode not supported.\n");
+- return -EINVAL;
++ ret = -EINVAL;
++ goto out;
+ }
+
+ /* make sure it is actually functional */
+@@ -252,7 +261,8 @@ static int __devinit mv_rtc_probe(struct
+ rtc_time = readl(pdata->ioaddr + RTC_TIME_REG_OFFS);
+ if (rtc_time == 0x01000000) {
+ dev_err(&pdev->dev, "internal RTC not ticking\n");
+- return -ENODEV;
++ ret = -ENODEV;
++ goto out;
+ }
+ }
+
+@@ -268,8 +278,10 @@ static int __devinit mv_rtc_probe(struct
+ } else
+ pdata->rtc = rtc_device_register(pdev->name, &pdev->dev,
+ &mv_rtc_ops, THIS_MODULE);
+- if (IS_ERR(pdata->rtc))
+- return PTR_ERR(pdata->rtc);
++ if (IS_ERR(pdata->rtc)) {
++ ret = PTR_ERR(pdata->rtc);
++ goto out;
++ }
+
+ if (pdata->irq >= 0) {
+ writel(0, pdata->ioaddr + RTC_ALARM_INTERRUPT_MASK_REG_OFFS);
+@@ -282,6 +294,11 @@ static int __devinit mv_rtc_probe(struct
+ }
+
+ return 0;
++out:
++ if (!IS_ERR(pdata->clk))
++ clk_disable_unprepare(pdata->clk);
++
++ return ret;
+ }
+
+ static int __exit mv_rtc_remove(struct platform_device *pdev)
+@@ -292,6 +309,9 @@ static int __exit mv_rtc_remove(struct p
+ device_init_wakeup(&pdev->dev, 0);
+
+ rtc_device_unregister(pdata->rtc);
++ if (!IS_ERR(pdata->clk))
++ clk_disable_unprepare(pdata->clk);
++
+ return 0;
+ }
+
hid-logitech-dj-do-not-directly-call-hid_output_raw_report-during-probe.patch
xen-pat-disable-pat-using-pat_enabled-value.patch
crypto-user-fix-info-leaks-in-report-api.patch
+keys-fix-race-with-concurrent-install_user_keyrings.patch
+fix-compat_rw_copy_check_uvector-misuse-in-aio-readv-writev-and-security-keys.patch
+vfs-fix-pipe-counter-breakage.patch
+rtc-rtc-mv-add-support-for-clk-to-avoid-lockups.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
+@@ -860,6 +860,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
