From: Greg Kroah-Hartman Date: Fri, 19 Mar 2010 03:57:31 +0000 (-0700) Subject: delete broken patches X-Git-Tag: v2.6.27.46~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a76f48224b747158f8e58e6681682d058f0e6bcb;p=thirdparty%2Fkernel%2Fstable-queue.git delete broken patches --- diff --git a/queue-2.6.32/b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch b/queue-2.6.32/b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch deleted file mode 100644 index 93751e8632b..00000000000 --- a/queue-2.6.32/b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch +++ /dev/null @@ -1,60 +0,0 @@ -From Larry.Finger@lwfinger.net Thu Mar 18 17:21:44 2010 -From: Larry Finger -Date: Wed, 10 Mar 2010 22:10:32 -0600 -Subject: b43: Workaround circular locking in hw-tkip key update callback -To: Greg Kroah-Hartman -Cc: Michael Buesch -Message-ID: <4b986d38.aOKVIPS3U9/aYsOP%Larry.Finger@lwfinger.net> - -From: Michael Buesch - -commit 96869a39399269a776a94812e9fff3d38b47d838 upstream - -The TKIP key update callback is called from the RX path, where the driver -mutex is already locked. This results in a circular locking bug. -Avoid this by removing the lock. - -Johannes noted that there is a separate bug: The callback still breaks on SDIO -hardware, because SDIO hardware access needs to sleep, but we are not allowed -to sleep in the callback due to mac80211's RCU locking. - -Signed-off-by: Michael Buesch -Tested-by: Larry Finger -Reported-by: kecsa@kutfo.hit.bme.hu -Cc: Johannes Berg -Signed-off-by: John W. Linville -Signed-off-by: Greg Kroah-Hartman - ---- - drivers/net/wireless/b43/main.c | 14 +++++++------- - 1 file changed, 7 insertions(+), 7 deletions(-) - ---- a/drivers/net/wireless/b43/main.c -+++ b/drivers/net/wireless/b43/main.c -@@ -852,19 +852,19 @@ static void b43_op_update_tkip_key(struc - if (B43_WARN_ON(!modparam_hwtkip)) - return; - -- mutex_lock(&wl->mutex); -- -+ /* This is only called from the RX path through mac80211, where -+ * our mutex is already locked. */ -+ B43_WARN_ON(!mutex_is_locked(&wl->mutex)); - dev = wl->current_dev; -- if (!dev || b43_status(dev) < B43_STAT_INITIALIZED) -- goto out_unlock; -+ B43_WARN_ON(!dev || b43_status(dev) < B43_STAT_INITIALIZED); - - keymac_write(dev, index, NULL); /* First zero out mac to avoid race */ - - rx_tkip_phase1_write(dev, index, iv32, phase1key); -+ /* only pairwise TKIP keys are supported right now */ -+ if (WARN_ON(!sta)) -+ return; - keymac_write(dev, index, addr); -- --out_unlock: -- mutex_unlock(&wl->mutex); - } - - static void do_key_write(struct b43_wldev *dev, diff --git a/queue-2.6.32/series b/queue-2.6.32/series index d1db570ccf8..c55325b7586 100644 --- a/queue-2.6.32/series +++ b/queue-2.6.32/series @@ -39,7 +39,5 @@ ath9k-fix-lockdep-warning-when-unloading-module.patch mqueue-fix-mq_open-file-descriptor-leak-on-user-space-processes.patch virtio-fix-out-of-range-array-access.patch x86-set_personality_ia32-misses-force_personality32.patch -b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch sched-fix-sched_mc-regression-caused-by-change-in-sched-cpu_power.patch readahead-add-blk_run_backing_dev.patch -thinkpad-acpi-lock-down-video-output-state-access.patch diff --git a/queue-2.6.32/thinkpad-acpi-lock-down-video-output-state-access.patch b/queue-2.6.32/thinkpad-acpi-lock-down-video-output-state-access.patch deleted file mode 100644 index 6b8e6aa3f22..00000000000 --- a/queue-2.6.32/thinkpad-acpi-lock-down-video-output-state-access.patch +++ /dev/null @@ -1,115 +0,0 @@ -From b525c06cdbd8a3963f0173ccd23f9147d4c384b5 Mon Sep 17 00:00:00 2001 -From: Henrique de Moraes Holschuh -Date: Thu, 25 Feb 2010 22:22:22 -0300 -Subject: thinkpad-acpi: lock down video output state access - -From: Henrique de Moraes Holschuh - -commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream. - -Given the right combination of ThinkPad and X.org, just reading the -video output control state is enough to hard-crash X.org. - -Until the day I somehow find out a model or BIOS cut date to not -provide this feature to ThinkPads that can do video switching through -X RandR, change permissions so that only processes with CAP_SYS_ADMIN -can access any sort of video output control state. - -This bug could be considered a local DoS I suppose, as it allows any -non-privledged local user to cause some versions of X.org to -hard-crash some ThinkPads. - -Reported-by: Jidanni -Signed-off-by: Henrique de Moraes Holschuh -Signed-off-by: Greg Kroah-Hartman - ---- a/Documentation/laptops/thinkpad-acpi.txt -+++ b/Documentation/laptops/thinkpad-acpi.txt -@@ -650,6 +650,10 @@ LCD, CRT or DVI (if available). The following commands are available: - echo expand_toggle > /proc/acpi/ibm/video - echo video_switch > /proc/acpi/ibm/video - -+NOTE: Access to this feature is restricted to processes owning the -+CAP_SYS_ADMIN capability for safety reasons, as it can interact badly -+enough with some versions of X.org to crash it. -+ - Each video output device can be enabled or disabled individually. - Reading /proc/acpi/ibm/video shows the status of each device. - -diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig -index f526e73..11fce79 100644 ---- a/drivers/platform/x86/Kconfig -+++ b/drivers/platform/x86/Kconfig -@@ -319,9 +319,15 @@ config THINKPAD_ACPI_VIDEO - server running, phase of the moon, and the current mood of - Schroedinger's cat. If you can use X.org's RandR to control - your ThinkPad's video output ports instead of this feature, -- don't think twice: do it and say N here to save some memory. -+ don't think twice: do it and say N here to save memory and avoid -+ bad interactions with X.org. - -- If you are not sure, say Y here. -+ NOTE: access to this feature is limited to processes with the -+ CAP_SYS_ADMIN capability, to avoid local DoS issues in platforms -+ where it interacts badly with X.org. -+ -+ If you are not sure, say Y here but do try to check if you could -+ be using X.org RandR instead. - - config THINKPAD_ACPI_HOTKEY_POLL - bool "Support NVRAM polling for hot keys" -diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c -index 3af4628..5d02cc0 100644 ---- a/drivers/platform/x86/thinkpad_acpi.c -+++ b/drivers/platform/x86/thinkpad_acpi.c -@@ -286,6 +286,7 @@ struct ibm_init_struct { - char param[32]; - - int (*init) (struct ibm_init_struct *); -+ mode_t base_procfs_mode; - struct ibm_struct *data; - }; - -@@ -4629,6 +4630,10 @@ static int video_read(struct seq_file *m) - return 0; - } - -+ /* Even reads can crash X.org, so... */ -+ if (!capable(CAP_SYS_ADMIN)) -+ return -EPERM; -+ - status = video_outputsw_get(); - if (status < 0) - return status; -@@ -4662,6 +4667,10 @@ static int video_write(char *buf) - if (video_supported == TPACPI_VIDEO_NONE) - return -ENODEV; - -+ /* Even reads can crash X.org, let alone writes... */ -+ if (!capable(CAP_SYS_ADMIN)) -+ return -EPERM; -+ - enable = 0; - disable = 0; - -@@ -8487,9 +8496,10 @@ static int __init ibm_init(struct ibm_init_struct *iibm) - "%s installed\n", ibm->name); - - if (ibm->read) { -- mode_t mode; -+ mode_t mode = iibm->base_procfs_mode; - -- mode = S_IRUGO; -+ if (!mode) -+ mode = S_IRUGO; - if (ibm->write) - mode |= S_IWUSR; - entry = proc_create_data(ibm->name, mode, proc_dir, -@@ -8680,6 +8690,7 @@ static struct ibm_init_struct ibms_init[] __initdata = { - #ifdef CONFIG_THINKPAD_ACPI_VIDEO - { - .init = video_init, -+ .base_procfs_mode = S_IRUSR, - .data = &video_driver_data, - }, - #endif diff --git a/queue-2.6.33/b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch b/queue-2.6.33/b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch deleted file mode 100644 index 93751e8632b..00000000000 --- a/queue-2.6.33/b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch +++ /dev/null @@ -1,60 +0,0 @@ -From Larry.Finger@lwfinger.net Thu Mar 18 17:21:44 2010 -From: Larry Finger -Date: Wed, 10 Mar 2010 22:10:32 -0600 -Subject: b43: Workaround circular locking in hw-tkip key update callback -To: Greg Kroah-Hartman -Cc: Michael Buesch -Message-ID: <4b986d38.aOKVIPS3U9/aYsOP%Larry.Finger@lwfinger.net> - -From: Michael Buesch - -commit 96869a39399269a776a94812e9fff3d38b47d838 upstream - -The TKIP key update callback is called from the RX path, where the driver -mutex is already locked. This results in a circular locking bug. -Avoid this by removing the lock. - -Johannes noted that there is a separate bug: The callback still breaks on SDIO -hardware, because SDIO hardware access needs to sleep, but we are not allowed -to sleep in the callback due to mac80211's RCU locking. - -Signed-off-by: Michael Buesch -Tested-by: Larry Finger -Reported-by: kecsa@kutfo.hit.bme.hu -Cc: Johannes Berg -Signed-off-by: John W. Linville -Signed-off-by: Greg Kroah-Hartman - ---- - drivers/net/wireless/b43/main.c | 14 +++++++------- - 1 file changed, 7 insertions(+), 7 deletions(-) - ---- a/drivers/net/wireless/b43/main.c -+++ b/drivers/net/wireless/b43/main.c -@@ -852,19 +852,19 @@ static void b43_op_update_tkip_key(struc - if (B43_WARN_ON(!modparam_hwtkip)) - return; - -- mutex_lock(&wl->mutex); -- -+ /* This is only called from the RX path through mac80211, where -+ * our mutex is already locked. */ -+ B43_WARN_ON(!mutex_is_locked(&wl->mutex)); - dev = wl->current_dev; -- if (!dev || b43_status(dev) < B43_STAT_INITIALIZED) -- goto out_unlock; -+ B43_WARN_ON(!dev || b43_status(dev) < B43_STAT_INITIALIZED); - - keymac_write(dev, index, NULL); /* First zero out mac to avoid race */ - - rx_tkip_phase1_write(dev, index, iv32, phase1key); -+ /* only pairwise TKIP keys are supported right now */ -+ if (WARN_ON(!sta)) -+ return; - keymac_write(dev, index, addr); -- --out_unlock: -- mutex_unlock(&wl->mutex); - } - - static void do_key_write(struct b43_wldev *dev, diff --git a/queue-2.6.33/series b/queue-2.6.33/series index 66a89131559..5a6c4278fa7 100644 --- a/queue-2.6.33/series +++ b/queue-2.6.33/series @@ -35,5 +35,4 @@ virtio-fix-out-of-range-array-access.patch iwlwifi-use-dma_alloc_coherent.patch can-fix-bfin_can-build-error-after-alloc_candev-change.patch perf-annotate-defer-allocating-sym_priv-hist-array.patch -b43-workaround-circular-locking-in-hw-tkip-key-update-callback.patch sched-fix-sched_mc-regression-caused-by-change-in-sched-cpu_power.patch