linux-stable.git/drivers/misc, branch v4.9.129

mei: bus: type promotion bug in mei_nfc_if_version()

2018-09-26T06:36:40+00:00

commit b40b3e9358fbafff6a4ba0f4b9658f6617146f9c upstream.

We accidentally removed the check for negative returns
without considering the issue of type promotion.
The "if_version_length" variable is type size_t so if __mei_cl_recv()
returns a negative then "bytes_recv" is type promoted
to a high positive value and treated as success.

Cc: 
Fixes: 582ab27a063a ("mei: bus: fix received data size check in NFC fixup")
Signed-off-by: Dan Carpenter 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman

mei: ignore not found client in the enumeration

2018-09-26T06:36:35+00:00

commit 8d2d8935d30cc2acc57a3196dc10dfa8d5cbcdab upstream.

Some of the ME clients are available only for BIOS operation and are
removed during hand off to an OS. However the removal is not instant.
A client may be visible on the client list when the mei driver requests
for enumeration, while the subsequent request for properties will be
answered with client not found error value. The default behavior
for an error is to perform client reset while this error is harmless and
the link reset should be prevented. This issue started to be visible due to
suspend/resume timing changes. Currently reported only on the Haswell
based system.

Fixes:
[33.564957] mei_me 0000:00:16.0: hbm: properties response: wrong status = 1 CLIENT_NOT_FOUND
[33.564978] mei_me 0000:00:16.0: mei_irq_read_handler ret = -71.
[33.565270] mei_me 0000:00:16.0: unexpected reset: dev_state = INIT_CLIENTS fw status = 1E000255 60002306 00000200 00004401 00000000 00000010

Cc: 
Reported-by: Heiner Kallweit 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman

misc: hmc6352: fix potential Spectre v1

2018-09-26T06:36:35+00:00

commit de916736aaaadddbd6061472969f667b14204aa9 upstream.

val is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/misc/hmc6352.c:54 compass_store() warn: potential spectre issue
'map' [r]

Fix this by sanitizing val before using it to index map

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman

misc: ti-st: Fix memory leak in the error path of probe()

2018-09-19T20:47:13+00:00

[ Upstream commit 81ae962d7f180c0092859440c82996cccb254976 ]

Free resources instead of direct return of the error code if kim_probe
fails.

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

Signed-off-by: Anton Vasilyev 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

misc: mic: SCIF Fix scif_get_new_port() error handling

2018-09-19T20:47:12+00:00

[ Upstream commit a39284ae9d2ad09975c8ae33f1bd0f05fbfbf6ee ]

There are only 2 callers of scif_get_new_port() and both appear to get
the error handling wrong.  Both treat zero returns as error, but it
actually returns negative error codes and >= 0 on success.

Fixes: e9089f43c9a7 ("misc: mic: SCIF open close bind and listen APIs")
Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mei: me: allow runtime pm for platform with D0i3

2018-09-15T07:43:06+00:00

commit cc365dcf0e56271bedf3de95f88922abe248e951 upstream.

>From the pci power documentation:
"The driver itself should not call pm_runtime_allow(), though. Instead,
it should let user space or some platform-specific code do that (user space
can do it via sysfs as stated above)..."

However, the S0ix residency cannot be reached without MEI device getting
into low power state. Hence, for mei devices that support D0i3, it's better
to make runtime power management mandatory and not rely on the system
integration such as udev rules.
This policy cannot be applied globally as some older platforms
were found to have broken power management.

Cc:  v4.13+
Cc: Rafael J. Wysocki 
Signed-off-by: Tomas Winkler 
Reviewed-by: Alexander Usyskin 
Signed-off-by: Greg Kroah-Hartman

vmw_balloon: fix VMCI use when balloon built into kernel

2018-09-09T18:01:22+00:00

commit c3cc1b0fc27508da53fe955a3b23d03964410682 upstream.

Currently, when all modules, including VMCI and VMware balloon are built
into the kernel, the initialization of the balloon happens before the
VMCI is probed. As a result, the balloon fails to initialize the VMCI
doorbell, which it uses to get asynchronous requests for balloon size
changes.

The problem can be seen in the logs, in the form of the following
message:
	"vmw_balloon: failed to initialize vmci doorbell"

The driver would work correctly but slightly less efficiently, probing
for requests periodically. This patch changes the balloon to be
initialized using late_initcall() instead of module_init() to address
this issue. It does not address a situation in which VMCI is built as a
module and the balloon is built into the kernel.

Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI")
Cc: stable@vger.kernel.org
Reviewed-by: Xavier Deguillard 
Signed-off-by: Nadav Amit 
Signed-off-by: Greg Kroah-Hartman

vmw_balloon: VMCI_DOORBELL_SET does not check status

2018-09-09T18:01:22+00:00

commit ce664331b2487a5d244a51cbdd8cb54f866fbe5d upstream.

When vmballoon_vmci_init() sets a doorbell using VMCI_DOORBELL_SET, for
some reason it does not consider the status and looks at the result.
However, the hypervisor does not update the result - it updates the
status. This might cause VMCI doorbell not to be enabled, resulting in
degraded performance.

Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI")
Cc: stable@vger.kernel.org
Reviewed-by: Xavier Deguillard 
Signed-off-by: Nadav Amit 
Signed-off-by: Greg Kroah-Hartman

vmw_balloon: do not use 2MB without batching

2018-09-09T18:01:22+00:00

commit 5081efd112560d3febb328e627176235b250d59d upstream.

If the hypervisor sets 2MB batching is on, while batching is cleared,
the balloon code breaks. In this case the legacy mechanism is used with
2MB page. The VM would report a 2MB page is ballooned, and the
hypervisor would only take the first 4KB.

While the hypervisor should not report such settings, make the code more
robust by not enabling 2MB support without batching.

Fixes: 365bd7ef7ec8e ("VMware balloon: Support 2m page ballooning.")
Cc: stable@vger.kernel.org
Reviewed-by: Xavier Deguillard 
Signed-off-by: Nadav Amit 
Signed-off-by: Greg Kroah-Hartman

vmw_balloon: fix inflation of 64-bit GFNs

2018-09-09T18:01:22+00:00

commit 09755690c6b7c1eabdc4651eb3b276f8feb1e447 upstream.

When balloon batching is not supported by the hypervisor, the guest
frame number (GFN) must fit in 32-bit. However, due to a bug, this check
was mistakenly ignored. In practice, when total RAM is greater than
16TB, the balloon does not work currently, making this bug unlikely to
happen.

Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
Cc: stable@vger.kernel.org
Reviewed-by: Xavier Deguillard 
Signed-off-by: Nadav Amit 
Signed-off-by: Greg Kroah-Hartman