linux-stable.git/drivers, branch v3.12.59

USB: usbip: fix potential out-of-bounds write

2016-04-23T07:24:41+00:00

commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb upstream.

Fix potential out-of-bounds write to urb->transfer_buffer
usbip handles network communication directly in the kernel. When receiving a
packet from its peer, usbip code parses headers according to protocol. As
part of this parsing urb->actual_length is filled. Since the input for
urb->actual_length comes from the network, it should be treated as untrusted.
Any entity controlling the network may put any value in the input and the
preallocated urb->transfer_buffer may not be large enough to hold the data.
Thus, the malicious entity is able to write arbitrary data to kernel memory.

Signed-off-by: Ignat Korchagin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

mmc: Allow forward compatibility for eMMC

2016-04-21T11:11:53+00:00

commit 03a59437ef6b6ad7fb0165cb9b96c08d6bf057fc upstream.

As stated by the eMMC 5.0 specification, a chip should not be rejected
only because of the revision stated in the EXT_CSD_REV field of the
EXT_CSD register.

Remove the control on this value, the control of the CSD_STRUCTURE field
should be sufficient to reject future incompatible changes.

Signed-off-by: Romain Izard 
Signed-off-by: Ulf Hansson 
Signed-off-by: Jiri Slaby

cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind

2016-04-21T11:11:52+00:00

commit 4d06dd537f95683aba3651098ae288b7cbff8274 upstream.

usbnet_link_change will call schedule_work and should be
avoided if bind is failing. Otherwise we will end up with
scheduled work referring to a netdev which has gone away.

Instead of making the call conditional, we can just defer
it to usbnet_probe, using the driver_info flag made for
this purpose.

Fixes: 8a34b0ae8778 ("usbnet: cdc_ncm: apply usbnet_link_change")
Reported-by: Andrey Konovalov 
Suggested-by: Linus Torvalds 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

net: qmi_wwan: MDM9x30 specific power management

2016-04-20T10:36:38+00:00

commit 93725149794d3d418cf1eddcae60c7b536c5faa1 upstream.

MDM9x30 based modems appear to go into a deeper sleep when
suspended without "Remote Wakeup" enabled.  The QMI interface
will not respond unless a "set DTR" control request is sent
on resume. The effect is similar to a QMI_CTL SYNC request,
resetting (some of) the firmware state.

We allow userspace sessions to span multiple character device
open/close sequences.  This means that userspace can depend
on firmware state while both the netdev and the character
device are closed.  We have disabled "needs_remote_wakeup" at
this point to allow devices without remote wakeup support to
be auto-suspended.

To make sure the MDM9x30 keeps firmware state, we need to
keep "needs_remote_wakeup" always set. We also need to
issue a "set DTR" request to enable the QMI interface.

Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

2016-04-20T06:54:54+00:00

commit 03d27ade4941076b34c823d63d91dc895731a595 upstream.

buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
devices.

That caused the OUT endpoint to freeze if the host send any data packet of
length greater than 256 bytes.

This is an example dump of what happended on that enpoint:
HOST:   [DATA][Length=260][...]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
...
HOST:   [PING]
DEVICE: [NAK]

This patch fixes this problem by setting the minimum usb_request's buffer size
for the OUT endpoint as its wMaxPacketSize.

Acked-by: Michal Nazarewicz 
Signed-off-by: Felipe F. Tonello 
Signed-off-by: Felipe Balbi 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby

jme: Fix device PM wakeup API usage

2016-04-20T06:50:28+00:00

commit 81422e672f8181d7ad1ee6c60c723aac649f538f upstream.

According to Documentation/power/devices.txt

The driver should not use device_set_wakeup_enable() which is the policy
for user to decide.

Using device_init_wakeup() to initialize dev->power.should_wakeup and
dev->power.can_wakeup on driver initialization.

And use device_may_wakeup() on suspend to decide if WoL function should
be enabled on NIC.

Reported-by: Diego Viola 
Signed-off-by: Guo-Fu Tseng 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

jme: Do not enable NIC WoL functions on S0

2016-04-20T06:50:20+00:00

commit 0772a99b818079e628a1da122ac7ee023faed83e upstream.

Otherwise it might be back on resume right after going to suspend in
some hardware.

Reported-by: Diego Viola 
Signed-off-by: Guo-Fu Tseng 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

usbvision: fix crash on detecting device with invalid configuration

2016-04-20T06:46:51+00:00

commit fa52bd506f274b7619955917abfde355e3d19ffe upstream.

The usbvision driver crashes when a specially crafted usb device with invalid
number of interfaces or endpoints is detected. This fix adds checks that the
device has proper configuration expected by the driver.

Reported-by: Ralf Spenneberg 
Signed-off-by: Vladis Dronov 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

usbvision: fix leak of usb_dev on failure paths in usbvision_probe()

2016-04-20T06:46:50+00:00

commit afd270d1a45043cef14341bcceff62ed50e8dc9a upstream.

There is no usb_put_dev() on failure paths in usbvision_probe().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jiri Slaby

drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)

2016-04-20T06:46:50+00:00

[Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with
 an additional NULL pointer guard that is required for kernels 3.17 and older.

 To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon:
 use common fence implementation for fences, v4" requires this additional
 NULL pointer guard.]

An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.

Based on the analogous fix for amdgpu.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Christian König  (v1 + fix)
Tested-by: Lutz Euler 
Signed-off-by: Jiri Slaby