From f7dbaabb9402ae540760a873bcd6a452c2e1acc3 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 12 Mar 2013 13:46:40 -0700 Subject: [PATCH] 3.4-stable patches added patches: fix-compat_rw_copy_check_uvector-misuse-in-aio-readv-writev-and-security-keys.patch fix-memory-leak-in-cpufreq-stats.patch keys-fix-race-with-concurrent-install_user_keyrings.patch rtc-rtc-mv-add-support-for-clk-to-avoid-lockups.patch vfs-fix-pipe-counter-breakage.patch --- ...n-aio-readv-writev-and-security-keys.patch | 127 ++++++++++++++++++ .../fix-memory-leak-in-cpufreq-stats.patch | 33 +++++ ...ith-concurrent-install_user_keyrings.patch | 72 ++++++++++ ...add-support-for-clk-to-avoid-lockups.patch | 125 +++++++++++++++++ queue-3.4/series | 5 + queue-3.4/vfs-fix-pipe-counter-breakage.patch | 42 ++++++ 6 files changed, 404 insertions(+) create mode 100644 queue-3.4/fix-compat_rw_copy_check_uvector-misuse-in-aio-readv-writev-and-security-keys.patch create mode 100644 queue-3.4/fix-memory-leak-in-cpufreq-stats.patch create mode 100644 queue-3.4/keys-fix-race-with-concurrent-install_user_keyrings.patch create mode 100644 queue-3.4/rtc-rtc-mv-add-support-for-clk-to-avoid-lockups.patch create mode 100644 queue-3.4/vfs-fix-pipe-counter-breakage.patch diff --git a/queue-3.4/fix-compat_rw_copy_check_uvector-misuse-in-aio-readv-writev-and-security-keys.patch b/queue-3.4/fix-compat_rw_copy_check_uvector-misuse-in-aio-readv-writev-and-security-keys.patch new file mode 100644 index 00000000000..8b60847df23 --- /dev/null +++ b/queue-3.4/fix-compat_rw_copy_check_uvector-misuse-in-aio-readv-writev-and-security-keys.patch @@ -0,0 +1,127 @@ +From 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 Mon Sep 17 00:00:00 2001 +From: Mathieu Desnoyers +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 + +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 +Acked-by: Al Viro +Signed-off-by: Mathieu Desnoyers +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.4/fix-memory-leak-in-cpufreq-stats.patch b/queue-3.4/fix-memory-leak-in-cpufreq-stats.patch new file mode 100644 index 00000000000..60f35c1770f --- /dev/null +++ b/queue-3.4/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 +@@ -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: diff --git a/queue-3.4/keys-fix-race-with-concurrent-install_user_keyrings.patch b/queue-3.4/keys-fix-race-with-concurrent-install_user_keyrings.patch new file mode 100644 index 00000000000..580386526ed --- /dev/null +++ b/queue-3.4/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.4/rtc-rtc-mv-add-support-for-clk-to-avoid-lockups.patch b/queue-3.4/rtc-rtc-mv-add-support-for-clk-to-avoid-lockups.patch new file mode 100644 index 00000000000..1c2f4b726c8 --- /dev/null +++ b/queue-3.4/rtc-rtc-mv-add-support-for-clk-to-avoid-lockups.patch @@ -0,0 +1,125 @@ +From 89c58c198b252f2bc20657fdd72a2aea788c435c Mon Sep 17 00:00:00 2001 +From: Andrew Lunn +Date: Sun, 3 Feb 2013 12:32:06 +0100 +Subject: rtc: rtc-mv: Add support for clk to avoid lockups + +From: Andrew Lunn + +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 +Signed-off-by: Andrew Lunn +Tested-by: Simon Baatz +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + #include + #include ++#include + #include + #include + +@@ -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; + } + diff --git a/queue-3.4/series b/queue-3.4/series index 2e4918d2f83..4bcaefc2e95 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -27,3 +27,8 @@ e1000e-fix-pci-device-enable-counter-balance.patch 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 diff --git a/queue-3.4/vfs-fix-pipe-counter-breakage.patch b/queue-3.4/vfs-fix-pipe-counter-breakage.patch new file mode 100644 index 00000000000..71ea88ec56e --- /dev/null +++ b/queue-3.4/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 +@@ -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) { -- 2.47.3