linux.git/drivers/misc, branch v5.1.13

Drivers: misc: fix out-of-bounds access in function param_set_kgdbts_var

2019-06-19T06:00:06+00:00

[ Upstream commit b281218ad4311a0342a40cb02fb17a363df08b48 ]

There is an out-of-bounds access to "config[len - 1]" array when the
variable "len" is zero.

See commit dada6a43b040 ("kgdboc: fix KASAN global-out-of-bounds bug
in param_set_kgdboc_var()") for details.

Signed-off-by: Young Xiao 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

misc: pci_endpoint_test: Fix test_reg_bar to be updated in pci_endpoint_test

2019-06-15T09:52:58+00:00

[ Upstream commit 8f220664570e755946db1282f48e07f26e1f2cb4 ]

commit 834b90519925 ("misc: pci_endpoint_test: Add support for
PCI_ENDPOINT_TEST regs to be mapped to any BAR") while adding
test_reg_bar in order to map PCI_ENDPOINT_TEST regs to be mapped to any
BAR failed to update test_reg_bar in pci_endpoint_test, resulting in
test_reg_bar having invalid value when used outside probe.

Fix it.

Fixes: 834b90519925 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR")
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin

genwqe: Prevent an integer overflow in the ioctl

2019-06-11T10:19:18+00:00

commit 110080cea0d0e4dfdb0b536e7f8a5633ead6a781 upstream.

There are a couple potential integer overflows here.

	round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE);

The first thing is that the "m->size + (...)" addition could overflow,
and the second is that round_up() overflows to zero if the result is
within PAGE_SIZE of the type max.

In this code, the "m->size" variable is an u64 but we're saving the
result in "map_size" which is an unsigned long and genwqe_user_vmap()
takes an unsigned long as well.  So I have used ULONG_MAX as the upper
bound.  From a practical perspective unsigned long is fine/better than
trying to change all the types to u64.

Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Signed-off-by: Dan Carpenter 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

habanalabs: fix debugfs code

2019-06-11T10:19:14+00:00

commit 8438846cce61e284a22316c13aa4b63772963070 upstream.

This fixes multiple things in the habanalabs debugfs code, in particular:

 - mmu_write() was unnecessarily verbose, copying around between multiple
   buffers
 - mmu_write() could write a user-specified, unbounded amount of userspace
   memory into a kernel buffer (out-of-bounds write)
 - multiple debugfs read handlers ignored the user-supplied count,
   potentially corrupting out-of-bounds userspace data
 - hl_device_read() was unnecessarily verbose
 - hl_device_write() could read uninitialized stack memory
 - multiple debugfs read handlers copied terminating null characters to
   userspace

Signed-off-by: Jann Horn 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Fix a possible double free

2019-05-31T13:43:46+00:00

[ Upstream commit b49f6d83e290f17e20f4e5cf31288d3bb4955ea6 ]

This patch fixes the error exit path of fastrpc_init_create_process().
If the DMA allocation or the DSP invoke fails the fastrpc_map was freed
but not removed from the mapping list leading to a double free once the
mapping list is emptied in fastrpc_device_release().

[srinivas kandagatla]: Cleaned up error path labels and reset init mem
to NULL after free
Fixes: d73f71c7c6ee("misc: fastrpc: Add support for create remote init process")
Signed-off-by: Thierry Escande 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

misc: fastrpc: make sure memory read and writes are visible

2019-05-31T13:43:46+00:00

[ Upstream commit 415a0729bd1225f0ffbc0ba82888dd65772554f7 ]

dma_alloc_coherent buffers could have writes queued in store buffers so
commit them before sending buffer to DSP using correct dma barriers.
Same with vice-versa.

Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

misc: fastrpc: consider address offset before sending to DSP

2019-05-31T13:43:46+00:00

[ Upstream commit 80f3afd72bd4149c57daf852905476b43bb47647 ]

While passing address phy address to DSP, take care of the offset
calculated from virtual address vma.

Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

habanalabs: prevent CPU soft lockup on Palladium

2019-05-31T13:43:44+00:00

[ Upstream commit e850b89f50d2c1439f58d547b888ee6e43312dea ]

Unmapping ptes in the device MMU on Palladium can take a long time, which
can cause a kernel BUG of CPU soft lockup.

This patch minimize the chances for this bug by sleeping a little between
unmapping ptes.

Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

habanalabs: all FD must be closed before removing device

2019-05-31T13:43:37+00:00

[ Upstream commit caa3c8e52582fc4d2ed82afd5e7ea164c18ef4fe ]

This patch fixes a bug in the implementation of the function that removes
the device.

The bug can happen when the device is removed but not the driver itself
(e.g. remove by the OS due to PCI freeze in Power architecture).

In that case, there maybe open users that are calling IOCTLs while the
device is removed. This is a possible race condition that the driver must
handle. Otherwise, a kernel panic may occur.

This race is prevented in the hard-reset flow, because the driver makes
sure the users are closed before continuing with the hard-reset. This
race can not occur when the driver itself is removed because the OS makes
sure all the file descriptors are closed.

The fix is to make sure the open users close their file descriptors and if
they don't (after a certain amount of time), the driver sends them a
SIGKILL, because the remove of the device can't be stopped.

The patch re-uses the same code that is called from the hard-reset flow.

Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

habanalabs: prevent device PTE read/write during hard-reset

2019-05-31T13:43:37+00:00

[ Upstream commit 9f201aba56b92c3daa4b76efae056ddbb80d91e6 ]

During hard-reset, contexts are closed as part of the tear-down process.
After a context is closed, the driver cleans up the page tables of that
context in the device's DRAM. This action is both dangerous and
unnecessary.

It is unnecessary, because the device is going through a hard-reset, which
means the device's DRAM contents are no longer valid and the device's MMU
is being reset.

It is dangerous, because if the hard-reset came as a result of a PCI
freeze, this action may cause the entire host machine to hang.

Therefore, prevent all device PTE updates when a hard-reset operation is
pending.

Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin