linux-stable.git/drivers, branch v4.7.7 Linux kernel stable tree Revert "usbtmc: convert to devm_kzalloc" 2016-10-07T13:21:28+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2016-09-28T09:48:44+00:00 c215a12f04e48ab817ac726e45110a8e0fb9f59e commit ab21b63e8aedfc73565dd9cdd51eb338341177cb upstream. This reverts commit e6c7efdcb76f11b04e3d3f71c8d764ab75c9423b. Turns out it was totally wrong. The memory is supposed to be bound to the kref, as the original code was doing correctly, not the device/driver binding as the devm_kzalloc() would cause. This fixes an oops when read would be called after the device was unbound from the driver. Reported-by: Ladislav Michl <ladis@linux-mips.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ab21b63e8aedfc73565dd9cdd51eb338341177cb upstream.

This reverts commit e6c7efdcb76f11b04e3d3f71c8d764ab75c9423b.

Turns out it was totally wrong.  The memory is supposed to be bound to
the kref, as the original code was doing correctly, not the
device/driver binding as the devm_kzalloc() would cause.

This fixes an oops when read would be called after the device was
unbound from the driver.

Reported-by: Ladislav Michl <ladis@linux-mips.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: serial: cp210x: Add ID for a Juniper console 2016-10-07T13:21:28+00:00 Kyle Jones kyle@kf5jwc.us 2016-09-23T18:28:37+00:00 bd2739690357696a1fa1a5b2ab5fc32f8f405f11 commit decc5360f23e9efe0252094f47f57f254dcbb3a9 upstream. Signed-off-by: Kyle Jones <kyle@kf5jwc.us> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit decc5360f23e9efe0252094f47f57f254dcbb3a9 upstream.

Signed-off-by: Kyle Jones <kyle@kf5jwc.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: usbip: vudc: fix left shift overflow 2016-10-07T13:21:28+00:00 Nicolas Iooss nicolas.iooss_linux@m4x.org 2016-08-23T15:13:29+00:00 57a265bc9d8d2c18f5577081588406e86dc0e9ab commit 238b7bd91b16d5a08326f858db42229b212e53d8 upstream. In v_recv_cmd_submit(), urb_p->urb->pipe has the type unsigned int (which is 32-bit long on x86_64) but 11<<30 results in a 34-bit integer. Therefore the 2 leading bits are truncated and urb_p->urb->pipe &= ~(11 << 30); has the same meaning as urb_p->urb->pipe &= ~(3 << 30); This second statement seems to be how the code was intended to be written, as PIPE_ constants have values between 0 and 3. The overflow has been detected with a clang warning: drivers/usb/usbip/vudc_rx.c:145:27: warning: signed shift result (0x2C0000000) requires 35 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] urb_p->urb->pipe &= ~(11 << 30); ~~ ^ ~~ Fixes: 79c02cb1fd5c ("usbip: vudc: Add vudc_rx") Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 238b7bd91b16d5a08326f858db42229b212e53d8 upstream.

In v_recv_cmd_submit(), urb_p->urb->pipe has the type unsigned int
(which is 32-bit long on x86_64) but 11<<30 results in a 34-bit integer.
Therefore the 2 leading bits are truncated and

    urb_p->urb->pipe &= ~(11 << 30);

has the same meaning as

    urb_p->urb->pipe &= ~(3 << 30);

This second statement seems to be how the code was intended to be
written, as PIPE_ constants have values between 0 and 3.

The overflow has been detected with a clang warning:

    drivers/usb/usbip/vudc_rx.c:145:27: warning: signed shift result
    (0x2C0000000) requires 35 bits to represent, but 'int' only has 32
    bits [-Wshift-overflow]
            urb_p->urb->pipe &= ~(11 << 30);
                                  ~~ ^  ~~

Fixes: 79c02cb1fd5c ("usbip: vudc: Add vudc_rx")
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Staging: fbtft: Fix bug in fbtft-core 2016-10-07T13:21:27+00:00 Ksenija Stanojevic ksenija.stanojevic@gmail.com 2016-10-02T15:42:35+00:00 41cba9cd039fc121285e96714683f74dc72137d4 commit fc1e2c8ea85e109acf09e74789e9b852f6eed251 upstream. Commit 367e8560e8d7a62d96e9b1d644028a3816e04206 introduced a bug in fbtft-core where fps is always 0, this is because variable update_time is not assigned correctly. Signed-off-by: Ksenija Stanojevic <ksenija.stanojevic@gmail.com> Fixes: 367e8560e8d7 ("Staging: fbtbt: Replace timespec with ktime_t") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fc1e2c8ea85e109acf09e74789e9b852f6eed251 upstream.

Commit 367e8560e8d7a62d96e9b1d644028a3816e04206 introduced a bug
in fbtft-core where fps is always 0, this is because variable
update_time is not assigned correctly.

Signed-off-by: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
Fixes: 367e8560e8d7 ("Staging: fbtbt: Replace timespec with ktime_t")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: misc: legousbtower: Fix NULL pointer deference 2016-10-07T13:21:27+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2016-09-19T18:09:51+00:00 03f8e90de1365975ea21fee41b0c16f558c466a8 commit 2fae9e5a7babada041e2e161699ade2447a01989 upstream. This patch fixes a NULL pointer dereference caused by a race codition in the probe function of the legousbtower driver. It re-structures the probe function to only register the interface after successfully reading the board's firmware ID. The probe function does not deregister the usb interface after an error receiving the devices firmware ID. The device file registered (/dev/usb/legousbtower%d) may be read/written globally before the probe function returns. When tower_delete is called in the probe function (after an r/w has been initiated), core dev structures are deleted while the file operation functions are still running. If the 0 address is mappable on the machine, this vulnerability can be used to create a Local Priviege Escalation exploit via a write-what-where condition by remapping dev->interrupt_out_buffer in tower_write. A forged USB device and local program execution would be required for LPE. The USB device would have to delay the control message in tower_probe and accept the control urb in tower_open whilst guest code initiated a write to the device file as tower_delete is called from the error in tower_probe. This bug has existed since 2003. Patch tested by emulated device. Reported-by: James Patrick-Evans <james@jmp-e.com> Tested-by: James Patrick-Evans <james@jmp-e.com> Signed-off-by: James Patrick-Evans <james@jmp-e.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2fae9e5a7babada041e2e161699ade2447a01989 upstream.

This patch fixes a NULL pointer dereference caused by a race codition in
the probe function of the legousbtower driver. It re-structures the
probe function to only register the interface after successfully reading
the board's firmware ID.

The probe function does not deregister the usb interface after an error
receiving the devices firmware ID. The device file registered
(/dev/usb/legousbtower%d) may be read/written globally before the probe
function returns. When tower_delete is called in the probe function
(after an r/w has been initiated), core dev structures are deleted while
the file operation functions are still running. If the 0 address is
mappable on the machine, this vulnerability can be used to create a
Local Priviege Escalation exploit via a write-what-where condition by
remapping dev->interrupt_out_buffer in tower_write. A forged USB device
and local program execution would be required for LPE. The USB device
would have to delay the control message in tower_probe and accept
the control urb in tower_open whilst guest code initiated a write to the
device file as tower_delete is called from the error in tower_probe.

This bug has existed since 2003. Patch tested by emulated device.

Reported-by: James Patrick-Evans <james@jmp-e.com>
Tested-by: James Patrick-Evans <james@jmp-e.com>
Signed-off-by: James Patrick-Evans <james@jmp-e.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dm log writes: fix bug with too large bios 2016-10-07T13:21:27+00:00 Mikulas Patocka mpatocka@redhat.com 2016-08-30T20:20:55+00:00 acae2cb2d9d9c7e1852ee38124f181c1443e7dc4 commit 7efb367320f56fc4d549875b6f3a6940018ef2e5 upstream. bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector entries. However, the incoming bio may have more vector entries if it was allocated by other means. For example, bcache submits bios with more than BIO_MAX_PAGES entries. This results in bio_alloc() failure. To avoid the failure, change the code so that it allocates bio with at most BIO_MAX_PAGES entries. If the incoming bio has more entries, bio_add_page() will fail and a new bio will be allocated - the code that handles bio_add_page() failure already exists in the dm-log-writes target. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7efb367320f56fc4d549875b6f3a6940018ef2e5 upstream.

bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector
entries.  However, the incoming bio may have more vector entries if it
was allocated by other means.  For example, bcache submits bios with
more than BIO_MAX_PAGES entries.  This results in bio_alloc() failure.

To avoid the failure, change the code so that it allocates bio with at
most BIO_MAX_PAGES entries.  If the incoming bio has more entries,
bio_add_page() will fail and a new bio will be allocated - the code that
handles bio_add_page() failure already exists in the dm-log-writes
target.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tpm_crb: fix mapping of the buffers 2016-10-07T13:21:27+00:00 Jarkko Sakkinen jarkko.sakkinen@linux.intel.com 2016-04-19T09:54:18+00:00 8e20d9300ac8d29bd5ce8f9e6f635af2c696bab8 commit 422eac3f7deae34dbaffd08e03e27f37a5394a56 upstream. On my Lenovo x250 the following situation occurs: [18697.813871] tpm_crb MSFT0101:00: can't request region for resource [mem 0xacdff080-0xacdfffff] The mapping of the control area overlaps the mapping of the command buffer. The control area is mapped over page, which is not right. It should mapped over sizeof(struct crb_control_area). Fixing this issue unmasks another issue. Command and response buffers can overlap and they do interleave on this machine. According to the PTP specification the overlapping means that they are mapped to the same buffer. The commit has been also on a Haswell NUC where things worked before applying this fix so that the both code paths for response buffer initialization are tested. Cc: stable@vger.kernel.org Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource") Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 422eac3f7deae34dbaffd08e03e27f37a5394a56 upstream.

On my Lenovo x250 the following situation occurs:

[18697.813871] tpm_crb MSFT0101:00: can't request region for resource
[mem 0xacdff080-0xacdfffff]

The mapping of the control area overlaps the mapping of the command
buffer. The control area is mapped over page, which is not right. It
should mapped over sizeof(struct crb_control_area).

Fixing this issue unmasks another issue. Command and response buffers
can overlap and they do interleave on this machine. According to the PTP
specification the overlapping means that they are mapped to the same
buffer.

The commit has been also on a Haswell NUC where things worked before
applying this fix so that the both code paths for response buffer
initialization are tested.

Cc: stable@vger.kernel.org
Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tpm_crb: drop struct resource res from struct crb_priv 2016-10-07T13:21:27+00:00 Jarkko Sakkinen jarkko.sakkinen@linux.intel.com 2016-03-15T19:41:40+00:00 5a58005763c3e66468814706eeb79999525a6cf5 commit 14ddfbf488a0223b19abf7e4634e6e676a91a12d upstream. The iomem resource is needed only temporarily so it is better to pass it on instead of storing it permanently. Named the variable as io_res so that the code better documents itself. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 14ddfbf488a0223b19abf7e4634e6e676a91a12d upstream.

The iomem resource is needed only temporarily so it is better to pass
it on instead of storing it permanently. Named the variable as io_res
so that the code better documents itself.

Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
IB/mlx5: Set source mac address in FTE 2016-10-07T13:21:27+00:00 Maor Gottlieb maorg@mellanox.com 2016-09-12T16:16:24+00:00 11e4257d6f382b890d872bd8c9fa5c9f266ce2b9 commit ee3da804ad1b1dd4c766199a6e8443542b0aaaef upstream. Set the source mac address in the FTE when L2 specification is provided. Fixes: 038d2ef87572 ('IB/mlx5: Add flow steering support') Signed-off-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ee3da804ad1b1dd4c766199a6e8443542b0aaaef upstream.

Set the source mac address in the FTE when L2 specification
is provided.

Fixes: 038d2ef87572 ('IB/mlx5: Add flow steering support')
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
IB/mlx5: Enable MAD_IFC commands for IB ports only 2016-10-07T13:21:27+00:00 Noa Osherovich noaos@mellanox.com 2016-09-12T16:16:23+00:00 d02402496370a80d6fe0d72a73d9a3b6b297cd1e commit 7fae6655a0c897875bd34501ec092232b526d3e4 upstream. MAD_IFC command is supported only for physical functions (PF) and when physical port is IB. The proposed fix enforces it. Fixes: d603c809ef91 ("IB/mlx5: Fix decision on using MAD_IFC") Reported-by: David Chang <dchang@suse.com> Signed-off-by: Noa Osherovich <noaos@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7fae6655a0c897875bd34501ec092232b526d3e4 upstream.

MAD_IFC command is supported only for physical functions (PF)
and when physical port is IB. The proposed fix enforces it.

Fixes: d603c809ef91 ("IB/mlx5: Fix decision on using MAD_IFC")
Reported-by: David Chang <dchang@suse.com>
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>