From: Greg Kroah-Hartman Date: Thu, 19 Apr 2012 20:05:03 +0000 (-0700) Subject: 3.3-stable patches X-Git-Tag: v3.2.16~5 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=15fa7b6f40abf66448684748136c07eace1a2272;p=thirdparty%2Fkernel%2Fstable-queue.git 3.3-stable patches added patches: drm-i915-hold-mode_config-lock-whilst-changing-mode-for-lastclose.patch drm-radeon-disable-msi-on-rv515.patch drm-radeon-fix-load-detect-on-rn50-with-hardcoded-edids.patch drm-radeon-kms-fix-the-regression-of-dvi-connector-check.patch futex-do-not-leak-robust-list-to-unprivileged-process.patch --- diff --git a/queue-3.3/drm-i915-hold-mode_config-lock-whilst-changing-mode-for-lastclose.patch b/queue-3.3/drm-i915-hold-mode_config-lock-whilst-changing-mode-for-lastclose.patch new file mode 100644 index 00000000000..c2f2a530410 --- /dev/null +++ b/queue-3.3/drm-i915-hold-mode_config-lock-whilst-changing-mode-for-lastclose.patch @@ -0,0 +1,42 @@ +From c291be9dba370ba696a0d482249a212cf5c15f45 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Mon, 16 Apr 2012 15:16:42 +0100 +Subject: drm/i915: Hold mode_config lock whilst changing mode for lastclose() + +From: Chris Wilson + +commit c291be9dba370ba696a0d482249a212cf5c15f45 upstream. + +Upon lastclose(), we switch back to the fbcon configuration. This +requires taking the mode_config lock in order to serialise the change +with output probing elsewhere. + +Reported-by: Oleksij Rempel +References: https://bugs.freedesktop.org/show_bug.cgi?id=48652 +Signed-off-by: Chris Wilson +Acked-by: Jesse Barnes +Signed-Off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_fb.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/gpu/drm/i915/intel_fb.c ++++ b/drivers/gpu/drm/i915/intel_fb.c +@@ -283,6 +283,8 @@ void intel_fb_restore_mode(struct drm_de + struct drm_mode_config *config = &dev->mode_config; + struct drm_plane *plane; + ++ mutex_lock(&dev->mode_config.mutex); ++ + ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper); + if (ret) + DRM_DEBUG("failed to restore crtc mode\n"); +@@ -290,4 +292,6 @@ void intel_fb_restore_mode(struct drm_de + /* Be sure to shut off any planes that may be active */ + list_for_each_entry(plane, &config->plane_list, head) + plane->funcs->disable_plane(plane); ++ ++ mutex_unlock(&dev->mode_config.mutex); + } diff --git a/queue-3.3/drm-radeon-disable-msi-on-rv515.patch b/queue-3.3/drm-radeon-disable-msi-on-rv515.patch new file mode 100644 index 00000000000..51b21f8ba70 --- /dev/null +++ b/queue-3.3/drm-radeon-disable-msi-on-rv515.patch @@ -0,0 +1,35 @@ +From 16a5e32b83fd946312b9b13590c75d20c95c5202 Mon Sep 17 00:00:00 2001 +From: Dave Airlie +Date: Fri, 13 Apr 2012 11:14:50 +0100 +Subject: drm/radeon: disable MSI on RV515 + +From: Dave Airlie + +commit 16a5e32b83fd946312b9b13590c75d20c95c5202 upstream. + +My rv515 card is very flaky with msi enabled. Every so often it loses a rearm +and never comes back, manually banging the rearm brings it back. + +Reviewed-by: Alex Deucher +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_irq_kms.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c ++++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c +@@ -147,6 +147,12 @@ static bool radeon_msi_ok(struct radeon_ + (rdev->pdev->subsystem_device == 0x01fd)) + return true; + ++ /* RV515 seems to have MSI issues where it loses ++ * MSI rearms occasionally. This leads to lockups and freezes. ++ * disable it by default. ++ */ ++ if (rdev->family == CHIP_RV515) ++ return false; + if (rdev->flags & RADEON_IS_IGP) { + /* APUs work fine with MSIs */ + if (rdev->family >= CHIP_PALM) diff --git a/queue-3.3/drm-radeon-fix-load-detect-on-rn50-with-hardcoded-edids.patch b/queue-3.3/drm-radeon-fix-load-detect-on-rn50-with-hardcoded-edids.patch new file mode 100644 index 00000000000..f742abaa474 --- /dev/null +++ b/queue-3.3/drm-radeon-fix-load-detect-on-rn50-with-hardcoded-edids.patch @@ -0,0 +1,43 @@ +From a09d431f344d854e4fe9cfac44f78cb8202f3eb7 Mon Sep 17 00:00:00 2001 +From: Dave Airlie +Date: Thu, 19 Apr 2012 15:42:58 +0100 +Subject: drm/radeon: fix load detect on rn50 with hardcoded EDIDs. + +From: Dave Airlie + +commit a09d431f344d854e4fe9cfac44f78cb8202f3eb7 upstream. + +When the force changes went in back in 3.3.0, we ended up returning +disconnected in the !force case, and the connected in when forced, +as it hit the hardcoded check. + +Fix it so all exits go via the hardcoded check and stop spurious +modesets on platforms with hardcoded EDIDs. + +Reported-by: Evan McNabb (Red Hat) +Reviewed-by: Alex Deucher +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_connectors.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/radeon/radeon_connectors.c ++++ b/drivers/gpu/drm/radeon/radeon_connectors.c +@@ -976,6 +976,7 @@ radeon_dvi_detect(struct drm_connector * + * cases the DVI port is actually a virtual KVM port connected to the service + * processor. + */ ++out: + if ((!rdev->is_atom_bios) && + (ret == connector_status_disconnected) && + rdev->mode_info.bios_hardcoded_edid_size) { +@@ -983,7 +984,6 @@ radeon_dvi_detect(struct drm_connector * + ret = connector_status_connected; + } + +-out: + /* updated in get modes as well since we need to know if it's analog or digital */ + radeon_connector_update_scratch_regs(connector, ret); + return ret; diff --git a/queue-3.3/drm-radeon-kms-fix-the-regression-of-dvi-connector-check.patch b/queue-3.3/drm-radeon-kms-fix-the-regression-of-dvi-connector-check.patch new file mode 100644 index 00000000000..86b5dd79992 --- /dev/null +++ b/queue-3.3/drm-radeon-kms-fix-the-regression-of-dvi-connector-check.patch @@ -0,0 +1,36 @@ +From e36325071832f1ba96ac54fb8ba1459f08b05dd8 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 18 Apr 2012 15:21:07 +0200 +Subject: drm/radeon/kms: fix the regression of DVI connector check + +From: Takashi Iwai + +commit e36325071832f1ba96ac54fb8ba1459f08b05dd8 upstream. + +The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms: +fix analog load detection on DVI-I connectors] is obviously wrong, and +it's the culprit of the regression on my workstation with DVI-analog +connection resulting in the blank output. + +Fixed the typo now. + +Signed-off-by: Takashi Iwai +Reviewed-by: Alex Deucher +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_connectors.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/radeon/radeon_connectors.c ++++ b/drivers/gpu/drm/radeon/radeon_connectors.c +@@ -946,7 +946,7 @@ radeon_dvi_detect(struct drm_connector * + + encoder = obj_to_encoder(obj); + +- if (encoder->encoder_type != DRM_MODE_ENCODER_DAC || ++ if (encoder->encoder_type != DRM_MODE_ENCODER_DAC && + encoder->encoder_type != DRM_MODE_ENCODER_TVDAC) + continue; + diff --git a/queue-3.3/futex-do-not-leak-robust-list-to-unprivileged-process.patch b/queue-3.3/futex-do-not-leak-robust-list-to-unprivileged-process.patch new file mode 100644 index 00000000000..7e1bfe300d2 --- /dev/null +++ b/queue-3.3/futex-do-not-leak-robust-list-to-unprivileged-process.patch @@ -0,0 +1,166 @@ +From bdbb776f882f5ad431aa1e694c69c1c3d6a4a5b8 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Mon, 19 Mar 2012 16:12:53 -0700 +Subject: futex: Do not leak robust list to unprivileged process + +From: Kees Cook + +commit bdbb776f882f5ad431aa1e694c69c1c3d6a4a5b8 upstream. + +It was possible to extract the robust list head address from a setuid +process if it had used set_robust_list(), allowing an ASLR info leak. This +changes the permission checks to be the same as those used for similar +info that comes out of /proc. + +Running a setuid program that uses robust futexes would have had: + cred->euid != pcred->euid + cred->euid == pcred->uid +so the old permissions check would allow it. I'm not aware of any setuid +programs that use robust futexes, so this is just a preventative measure. + +(This patch is based on changes from grsecurity.) + +Signed-off-by: Kees Cook +Cc: Darren Hart +Cc: Peter Zijlstra +Cc: Jiri Kosina +Cc: Eric W. Biederman +Cc: David Howells +Cc: Serge E. Hallyn +Cc: kernel-hardening@lists.openwall.com +Cc: spender@grsecurity.net +Link: http://lkml.kernel.org/r/20120319231253.GA20893@www.outflux.net +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 36 +++++++++++++----------------------- + kernel/futex_compat.c | 36 +++++++++++++----------------------- + 2 files changed, 26 insertions(+), 46 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -59,6 +59,7 @@ + #include + #include + #include ++#include + + #include + +@@ -2443,40 +2444,29 @@ SYSCALL_DEFINE3(get_robust_list, int, pi + { + struct robust_list_head __user *head; + unsigned long ret; +- const struct cred *cred = current_cred(), *pcred; ++ struct task_struct *p; + + if (!futex_cmpxchg_enabled) + return -ENOSYS; + ++ rcu_read_lock(); ++ ++ ret = -ESRCH; + if (!pid) +- head = current->robust_list; ++ p = current; + else { +- struct task_struct *p; +- +- ret = -ESRCH; +- rcu_read_lock(); + p = find_task_by_vpid(pid); + if (!p) + goto err_unlock; +- ret = -EPERM; +- pcred = __task_cred(p); +- /* If victim is in different user_ns, then uids are not +- comparable, so we must have CAP_SYS_PTRACE */ +- if (cred->user->user_ns != pcred->user->user_ns) { +- if (!ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE)) +- goto err_unlock; +- goto ok; +- } +- /* If victim is in same user_ns, then uids are comparable */ +- if (cred->euid != pcred->euid && +- cred->euid != pcred->uid && +- !ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE)) +- goto err_unlock; +-ok: +- head = p->robust_list; +- rcu_read_unlock(); + } + ++ ret = -EPERM; ++ if (!ptrace_may_access(p, PTRACE_MODE_READ)) ++ goto err_unlock; ++ ++ head = p->robust_list; ++ rcu_read_unlock(); ++ + if (put_user(sizeof(*head), len_ptr)) + return -EFAULT; + return put_user(head, head_ptr); +--- a/kernel/futex_compat.c ++++ b/kernel/futex_compat.c +@@ -10,6 +10,7 @@ + #include + #include + #include ++#include + + #include + +@@ -136,40 +137,29 @@ compat_sys_get_robust_list(int pid, comp + { + struct compat_robust_list_head __user *head; + unsigned long ret; +- const struct cred *cred = current_cred(), *pcred; ++ struct task_struct *p; + + if (!futex_cmpxchg_enabled) + return -ENOSYS; + ++ rcu_read_lock(); ++ ++ ret = -ESRCH; + if (!pid) +- head = current->compat_robust_list; ++ p = current; + else { +- struct task_struct *p; +- +- ret = -ESRCH; +- rcu_read_lock(); + p = find_task_by_vpid(pid); + if (!p) + goto err_unlock; +- ret = -EPERM; +- pcred = __task_cred(p); +- /* If victim is in different user_ns, then uids are not +- comparable, so we must have CAP_SYS_PTRACE */ +- if (cred->user->user_ns != pcred->user->user_ns) { +- if (!ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE)) +- goto err_unlock; +- goto ok; +- } +- /* If victim is in same user_ns, then uids are comparable */ +- if (cred->euid != pcred->euid && +- cred->euid != pcred->uid && +- !ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE)) +- goto err_unlock; +-ok: +- head = p->compat_robust_list; +- rcu_read_unlock(); + } + ++ ret = -EPERM; ++ if (!ptrace_may_access(p, PTRACE_MODE_READ)) ++ goto err_unlock; ++ ++ head = p->compat_robust_list; ++ rcu_read_unlock(); ++ + if (put_user(sizeof(*head), len_ptr)) + return -EFAULT; + return put_user(ptr_to_compat(head), head_ptr); diff --git a/queue-3.3/series b/queue-3.3/series index 3b7cd1ec8c1..37c3812389b 100644 --- a/queue-3.3/series +++ b/queue-3.3/series @@ -68,3 +68,8 @@ security-fix-compile-error-in-commoncap.c.patch spi-topcliff-pch-fix-wuninitialized-warning.patch bluetooth-adding-usb-device-13d3-3375-as-an-atheros-ar3012.patch bluetooth-add-atheros-maryann-pidvid-support.patch +futex-do-not-leak-robust-list-to-unprivileged-process.patch +drm-i915-hold-mode_config-lock-whilst-changing-mode-for-lastclose.patch +drm-radeon-kms-fix-the-regression-of-dvi-connector-check.patch +drm-radeon-disable-msi-on-rv515.patch +drm-radeon-fix-load-detect-on-rn50-with-hardcoded-edids.patch