linux/drivers, branch v3.9.10

SCSI: sd: Fix parsing of 'temporary ' cache mode prefix

2013-07-13T18:39:18Z

commit 2ee3e26c673e75c05ef8b914f54fadee3d7b9c88 upstream. Commit 39c60a0948cc '[SCSI] sd: fix array cache flushing bug causing performance problems' added temp as a pointer to "temporary " and used sizeof(temp) - 1 as its length. But sizeof(temp) is the size of the pointer, not the size of the string constant. Change temp to a static array so that sizeof() does what was intended. Signed-off-by: Ben Hutchings Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"

2013-07-13T18:39:18Z

commit 828c6a102b1f2b8583fadc0e779c46b31d448f0b upstream. This reverts commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366. As reported by Stefan, this device already works with the parport_serial driver, so the 8250_pci driver should not also try to grab it as well. Reported-by: Stefan Seyfried Cc: Wang YanQing Signed-off-by: Greg Kroah-Hartman

block: do not pass disk names as format strings

2013-07-13T18:39:17Z

commit ffc8b30866879ed9ba62bd0a86fecdbd51cd3d19 upstream. Disk names may contain arbitrary strings, so they must not be interpreted as format strings. It seems that only md allows arbitrary strings to be used for disk names, but this could allow for a local memory corruption from uid 0 into ring 0. CVE-2013-2851 Signed-off-by: Kees Cook Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

charger-manager: Ensure event is not used as format string

2013-07-13T18:39:17Z

commit 3594f4c0d7bc51e3a7e6d73c44e368ae079e42f3 upstream. The exposed interface for cm_notify_event() could result in the event msg string being parsed as a format string. Make sure it is only used as a literal string. Signed-off-by: Kees Cook Cc: Anton Vorontsov Cc: David Woodhouse Signed-off-by: Anton Vorontsov Signed-off-by: Greg Kroah-Hartman

drivers/cdrom/cdrom.c: use kzalloc() for failing hardware

2013-07-13T18:39:17Z

commit 542db01579fbb7ea7d1f7bb9ddcef1559df660b2 upstream. In drivers/cdrom/cdrom.c mmc_ioctl_cdrom_read_data() allocates a memory area with kmalloc in line 2885. 2885 cgc->buffer = kmalloc(blocksize, GFP_KERNEL); 2886 if (cgc->buffer == NULL) 2887 return -ENOMEM; In line 2908 we can find the copy_to_user function: 2908 if (!ret && copy_to_user(arg, cgc->buffer, blocksize)) The cgc->buffer is never cleaned and initialized before this function. If ret = 0 with the previous basic block, it's possible to display some memory bytes in kernel space from userspace. When we read a block from the disk it normally fills the ->buffer but if the drive is malfunctioning there is a chance that it would only be partially filled. The result is an leak information to userspace. Signed-off-by: Dan Carpenter Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Jonathan Salwan Cc: Luis Henriques Signed-off-by: Greg Kroah-Hartman

can: usb_8dev: unregister netdev before free()ing

2013-07-03T17:55:37Z

commit 4afe2156eb639e563d6ef0c2706b66ea400348b2 upstream. The usb_8dev hardware has problems on some xhci USB hosts. The driver fails to read the firmware revision in the probe function. This leads to the following Oops: [ 3356.635912] kernel BUG at net/core/dev.c:5701! The driver tries to free the netdev, which has already been registered, without unregistering it. This patch fixes the problem by unregistering the netdev in the error path. Reported-by: Michael Olbrich Reviewed-by: Bernd Krumboeck Signed-off-by: Marc Kleine-Budde Cc: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman

of/base: release the node correctly in of_parse_phandle_with_args()

2013-07-03T17:55:36Z

commit b855f16b05a697ac1863adabe99bfba56e6d3199 upstream. Call of_node_put() only when the out_args is NULL on success, or the node's reference count will not be correct because the caller will call of_node_put() again. Signed-off-by: Tang Yuantian [grant.likely: tightened up the patch] Signed-off-by: Grant Likely Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

libata-acpi: add back ACPI based hotplug functionality

2013-07-03T17:55:36Z

commit 44521527be36172864e6e7a6fba4b66e9aa48e40 upstream. Commit 30dcf76acc69 "libata: migrate ACPI code over to new bindings" mistakenly dropped the code to register hotplug notificaion handler for ATA port/devices, causing regression for people using ATA bay, as kernel bug #59871 shows. Fix this by adding back the hotplug notification handler registration code. Since this code has to be run once and notification needs to be installed on every ATA port/devices handle no matter if there is actual device attached, we can't do this in binding time for ATA device ACPI handle, as the binding only occurs when a SCSI device is created, i.e. there is device attached. So introduce the ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles and if it is available, install the notificaion handler for it during ATA init time. With the ATA ACPI handle binding to SCSI device tree, it is possible now that when the SCSI hotplug work removes the SCSI device, the ACPI unbind function will find that the corresponding ACPI device has already been deleted by dock driver, causing a scaring message like: [ 128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt Fix this by waiting for SCSI hotplug task finish in our notificaion handler, so that the removal of ACPI device done in ACPI unbind function triggered by the removal of SCSI device is run earlier when ACPI device is still available. [The only change I've made is to remove the two NULL params in register_hotplug_dock_device, which doesn't accept those params in pre-v3.10 kernels. - aaron.lu] [rjw: Rebased] References: https://bugzilla.kernel.org/show_bug.cgi?id=59871 Reported-bisected-and-tested-by: Dirk Griesbach Signed-off-by: Aaron Lu Acked-by: Tejun Heo Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

2013-07-03T17:55:22Z

commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream. A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500 chipsets which contained an errata (specificially errata 53), which noted that these chipsets can't properly do interrupt remapping, and as a result the recommend that interrupt remapping be disabled in bios. While many vendors have a bios update to do exactly that, not all do, and of course not all users update their bios to a level that corrects the problem. As a result, occasionally interrupts can arrive at a cpu even after affinity for that interrupt has be moved, leading to lost or spurrious interrupts (usually characterized by the message: kernel: do_IRQ: 7.71 No irq handler for vector (irq -1) There have been several incidents recently of people seeing this error, and investigation has shown that they have system for which their BIOS level is such that this feature was not properly turned off. As such, it would be good to give them a reminder that their systems are vulnurable to this problem. For details of those that reported the problem, please see: https://bugzilla.redhat.com/show_bug.cgi?id=887006 [ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ] Signed-off-by: Neil Horman CC: Prarit Bhargava CC: Don Zickus CC: Don Dutile CC: Bjorn Helgaas CC: Asit Mallick CC: David Woodhouse CC: linux-pci@vger.kernel.org CC: Joerg Roedel CC: Konrad Rzeszutek Wilk CC: Arkadiusz Miśkiewicz Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

rt2800: fix RT5390 & RT3290 TX power settings regression

2013-07-03T17:55:22Z

commit 8c8d2017ba25c510ddf093419048460db1109bc4 upstream. My change: commit cee2c7315f60beeff6137ee59e99acc77d636eeb Author: Stanislaw Gruszka Date: Fri Oct 5 13:44:09 2012 +0200 rt2800: use BBP_R1 for setting tx power unfortunately does not work well with RT5390 and RT3290 chips as they require different temperature compensation TX power settings (TSSI tuning). Since that commit make wireless connection very unstable on those chips, restore previous behavior to fix regression. Once we implement proper TSSI tuning on 5390/3290 we can restore back setting TX power by BBP_R1 register for those chips. Reported-and-tested-by: Mike Romberg Signed-off-by: Stanislaw Gruszka Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman