linux-stable.git/drivers, branch v4.6.6 Linux kernel stable tree intel_th: Fix a deadlock in modprobing 2016-08-10T10:54:50+00:00 Alexander Shishkin alexander.shishkin@linux.intel.com 2016-06-30T08:51:44+00:00 900ac92c5514dd8c63a8f3c91942dcb4cc6bd0f3 commit a36aa80f3cb2540fb1dbad6240852de4365a2e82 upstream. Driver initialization tries to request a hub (GTH) driver module from its probe callback, resulting in a deadlock. This patch solves the problem by adding a deferred work for requesting the hub module. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a36aa80f3cb2540fb1dbad6240852de4365a2e82 upstream.

Driver initialization tries to request a hub (GTH) driver module from
its probe callback, resulting in a deadlock.

This patch solves the problem by adding a deferred work for requesting
the hub module.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
intel_th: pci: Add Kaby Lake PCH-H support 2016-08-10T10:54:49+00:00 Alexander Shishkin alexander.shishkin@linux.intel.com 2016-06-28T15:55:23+00:00 df1abbea005a621a497fc9def893ed2c6cba4d94 commit 7a1a47ce35821b40f5b2ce46379ba14393bc3873 upstream. This adds Intel(R) Trace Hub PCI ID for Kaby Lake PCH-H. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7a1a47ce35821b40f5b2ce46379ba14393bc3873 upstream.

This adds Intel(R) Trace Hub PCI ID for Kaby Lake PCH-H.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: mvneta: set real interrupt per packet for tx_done 2016-08-10T10:54:49+00:00 Dmitri Epshtein dima@marvell.com 2016-07-06T02:18:58+00:00 2f4cf2ec9191577c201aaf71cca4ccabb50cdb8e commit 06708f81528725148473c0869d6af5f809c6824b upstream. Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to set coalescing threshold to a value guaranteeing interrupt generation per each sent packet, so that buffers can be released with no delay. In fact setting threshold to '1' was wrong, because it causes interrupt every two packets. According to the documentation a reason behind it is following - interrupt occurs once sent buffers counter reaches a value, which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This behavior was confirmed during tests. Also when testing the SoC working as a NAS device, better performance was observed with int-per-packet, as it strongly depends on the fact that all transmitted packets are released immediately. This commit enables NETA controller work in interrupt per sent packet mode by setting coalescing threshold to 0. Signed-off-by: Dmitri Epshtein <dima@marvell.com> Signed-off-by: Marcin Wojtas <mw@semihalf.com> Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") Acked-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 06708f81528725148473c0869d6af5f809c6824b upstream.

Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
set coalescing threshold to a value guaranteeing interrupt generation
per each sent packet, so that buffers can be released with no delay.

In fact setting threshold to '1' was wrong, because it causes interrupt
every two packets. According to the documentation a reason behind it is
following - interrupt occurs once sent buffers counter reaches a value,
which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
behavior was confirmed during tests. Also when testing the SoC working
as a NAS device, better performance was observed with int-per-packet,
as it strongly depends on the fact that all transmitted packets are
released immediately.

This commit enables NETA controller work in interrupt per sent packet mode
by setting coalescing threshold to 0.

Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
libata: LITE-ON CX1-JB256-HP needs lower max_sectors 2016-08-10T10:54:49+00:00 Tejun Heo tj@kernel.org 2016-07-18T22:40:00+00:00 54d61751bb7296a3986f571b915e8f5924e7956e commit 1488a1e3828d60d74c9b802a05e24c0487babe4e upstream. Since 34b48db66e08 ("block: remove artifical max_hw_sectors cap"), max_sectors is no longer limited to BLK_DEF_MAX_SECTORS and LITE-ON CX1-JB256-HP keeps timing out with higher max_sectors. Revert it to the previous value. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: dgerasimov@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=121671 Fixes: 34b48db66e08 ("block: remove artifical max_hw_sectors cap") Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1488a1e3828d60d74c9b802a05e24c0487babe4e upstream.

Since 34b48db66e08 ("block: remove artifical max_hw_sectors cap"),
max_sectors is no longer limited to BLK_DEF_MAX_SECTORS and LITE-ON
CX1-JB256-HP keeps timing out with higher max_sectors.  Revert it to
the previous value.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: dgerasimov@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=121671
Fixes: 34b48db66e08 ("block: remove artifical max_hw_sectors cap")
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c: mux: reg: wrong condition checked for of_address_to_resource return value 2016-08-10T10:54:49+00:00 Lukasz Gemborowski lukasz.gemborowski@nokia.com 2016-06-27T10:57:47+00:00 ed87c21407e4d781dc88c4b4fce0113336ba501d commit 22ebf00eb56fe77922de8138aa9af9996582c2b3 upstream. of_address_to_resource return 0 on successful call but devm_ioremap_resource is called only if it returns non-zero value Signed-off-by: Lukasz Gemborowski <lukasz.gemborowski@nokia.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 22ebf00eb56fe77922de8138aa9af9996582c2b3 upstream.

of_address_to_resource return 0 on successful call but
devm_ioremap_resource is called only if it returns non-zero value

Signed-off-by: Lukasz Gemborowski <lukasz.gemborowski@nokia.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c: qup: Fix wrong value of index variable 2016-08-10T10:54:49+00:00 Sricharan R sricharan@codeaurora.org 2016-06-10T18:08:20+00:00 f5be1dff829038ff2225238291c67fdeb7caa0c9 commit d4f56c7773483b8829e89cfc739b7a5a071f6da0 upstream. index gets incremented during check to determine if the messages can be transferred with dma. But not reset after that, resulting in wrong start value in subsequent loop, causing failure. Fix it. Signed-off-by: Sricharan R <sricharan@codeaurora.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d4f56c7773483b8829e89cfc739b7a5a071f6da0 upstream.

index gets incremented during check to determine if the
messages can be transferred with dma. But not reset after
that, resulting in wrong start value in subsequent loop,
causing failure. Fix it.

Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
adv7604: Don't ignore pad number in subdev DV timings pad operations 2016-08-10T10:54:49+00:00 Laurent Pinchart laurent.pinchart@ideasonboard.com 2016-05-24T12:09:33+00:00 9388174e5d878444e78103f9e97e656a463bc5e4 commit 6519c3d7b8621c9f4333c98ed4b703029b51ba79 upstream. The dv_timings_cap() and enum_dv_timings() pad operations take a pad number as an input argument and return the DV timings capabilities and list of supported DV timings for that pad. Commit bd3e275f3ec0 ("[media] media: i2c: adv7604: Use v4l2-dv-timings helpers") broke this as it started ignoring the pad number, always returning the information associated with the currently selected input. Fix it. Fixes: bd3e275f3ec0 ("[media] media: i2c: adv7604: Use v4l2-dv-timings helpers") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6519c3d7b8621c9f4333c98ed4b703029b51ba79 upstream.

The dv_timings_cap() and enum_dv_timings() pad operations take a pad
number as an input argument and return the DV timings capabilities and
list of supported DV timings for that pad.

Commit bd3e275f3ec0 ("[media] media: i2c: adv7604: Use v4l2-dv-timings
helpers") broke this as it started ignoring the pad number, always
returning the information associated with the currently selected input.
Fix it.

Fixes: bd3e275f3ec0 ("[media] media: i2c: adv7604: Use v4l2-dv-timings helpers")

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: fix airspy usb probe error path 2016-08-10T10:54:49+00:00 James Patrick-Evans james@jmp-e.com 2016-07-15T15:40:45+00:00 1031db3dff78793352bbda8ab5391def6f372aa4 commit aa93d1fee85c890a34f2510a310e55ee76a27848 upstream. Fix a memory leak on probe error of the airspy usb device driver. The problem is triggered when more than 64 usb devices register with v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV. The memory leak is caused by the probe function of the airspy driver mishandeling errors and not freeing the corresponding control structures when an error occours registering the device to v4l2 core. A badusb device can emulate 64 of these devices, and then through continual emulated connect/disconnect of the 65th device, cause the kernel to run out of RAM and crash the kernel, thus causing a local DOS vulnerability. Fixes CVE-2016-5400 Signed-off-by: James Patrick-Evans <james@jmp-e.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit aa93d1fee85c890a34f2510a310e55ee76a27848 upstream.

Fix a memory leak on probe error of the airspy usb device driver.

The problem is triggered when more than 64 usb devices register with
v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV.

The memory leak is caused by the probe function of the airspy driver
mishandeling errors and not freeing the corresponding control structures
when an error occours registering the device to v4l2 core.

A badusb device can emulate 64 of these devices, and then through
continual emulated connect/disconnect of the 65th device, cause the
kernel to run out of RAM and crash the kernel, thus causing a local DOS
vulnerability.

Fixes CVE-2016-5400

Signed-off-by: James Patrick-Evans <james@jmp-e.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipr: Clear interrupt on croc/crocodile when running with LSI 2016-08-10T10:54:49+00:00 Brian King brking@linux.vnet.ibm.com 2016-06-27T14:09:40+00:00 602efc3c6731484a497871abf557290fe4d104be commit 54e430bbd490e18ab116afa4cd90dcc45787b3df upstream. If we fall back to using LSI on the Croc or Crocodile chip we need to clear the interrupt so we don't hang the system. Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 54e430bbd490e18ab116afa4cd90dcc45787b3df upstream.

If we fall back to using LSI on the Croc or Crocodile chip we need to
clear the interrupt so we don't hang the system.

Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SCSI: fix new bug in scsi_dev_info_list string matching 2016-08-10T10:54:48+00:00 Alan Stern stern@rowland.harvard.edu 2016-06-23T19:05:26+00:00 224d3cc7716dac2372df2b52df78067b3482a751 commit 5e7ff2ca7f2da55fe777167849d0c93403bd0dc8 upstream. Commit b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching") changed the way vendor- and model-string matching was carried out in the routine that looks up entries in a SCSI devinfo list. The new matching code failed to take into account the case of a maximum-length string; in such cases it could end up testing for a terminating '\0' byte beyond the end of the memory allocated to the string. This out-of-bounds bug was detected by UBSAN. I don't know if anybody has actually encountered this bug. The symptom would be that a device entry in the blacklist might not be matched properly if it contained an 8-character vendor name or a 16-character model name. Such entries certainly exist in scsi_static_device_list. This patch fixes the problem by adding a check for a maximum-length string before the '\0' test. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching") Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5e7ff2ca7f2da55fe777167849d0c93403bd0dc8 upstream.

Commit b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching")
changed the way vendor- and model-string matching was carried out in the
routine that looks up entries in a SCSI devinfo list.  The new matching
code failed to take into account the case of a maximum-length string; in
such cases it could end up testing for a terminating '\0' byte beyond
the end of the memory allocated to the string.  This out-of-bounds bug
was detected by UBSAN.

I don't know if anybody has actually encountered this bug.  The symptom
would be that a device entry in the blacklist might not be matched
properly if it contained an 8-character vendor name or a 16-character
model name.  Such entries certainly exist in scsi_static_device_list.

This patch fixes the problem by adding a check for a maximum-length
string before the '\0' test.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: b704f70ce200 ("SCSI: fix bug in scsi_dev_info_list matching")
Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>