+++ /dev/null
-From Larry.Finger@lwfinger.net Thu Mar 18 17:21:44 2010
-From: Larry Finger <Larry.Finger@lwfinger.net>
-Date: Wed, 10 Mar 2010 22:10:32 -0600
-Subject: b43: Workaround circular locking in hw-tkip key update callback
-To: Greg Kroah-Hartman <gregkh@suse.de>
-Cc: Michael Buesch <mb@bu3sch.de>
-Message-ID: <4b986d38.aOKVIPS3U9/aYsOP%Larry.Finger@lwfinger.net>
-
-From: Michael Buesch <mb@bu3sch.de>
-
-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 <mb@bu3sch.de>
-Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
-Reported-by: kecsa@kutfo.hit.bme.hu
-Cc: Johannes Berg <johannes@sipsolutions.net>
-Signed-off-by: John W. Linville <linville@tuxdriver.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
----
- 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,
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
+++ /dev/null
-From b525c06cdbd8a3963f0173ccd23f9147d4c384b5 Mon Sep 17 00:00:00 2001
-From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
-Date: Thu, 25 Feb 2010 22:22:22 -0300
-Subject: thinkpad-acpi: lock down video output state access
-
-From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
-
-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 <jidanni@jidanni.org>
-Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
-Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
---- 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
+++ /dev/null
-From Larry.Finger@lwfinger.net Thu Mar 18 17:21:44 2010
-From: Larry Finger <Larry.Finger@lwfinger.net>
-Date: Wed, 10 Mar 2010 22:10:32 -0600
-Subject: b43: Workaround circular locking in hw-tkip key update callback
-To: Greg Kroah-Hartman <gregkh@suse.de>
-Cc: Michael Buesch <mb@bu3sch.de>
-Message-ID: <4b986d38.aOKVIPS3U9/aYsOP%Larry.Finger@lwfinger.net>
-
-From: Michael Buesch <mb@bu3sch.de>
-
-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 <mb@bu3sch.de>
-Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
-Reported-by: kecsa@kutfo.hit.bme.hu
-Cc: Johannes Berg <johannes@sipsolutions.net>
-Signed-off-by: John W. Linville <linville@tuxdriver.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
----
- 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,
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
