<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/misc, branch v4.18.11</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.18.11</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.18.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2018-09-29T09:56:02+00:00</updated>
<entry>
<title>vmw_balloon: include asm/io.h</title>
<updated>2018-09-29T09:56:02+00:00</updated>
<author>
<name>Nadav Amit</name>
<email>namit@vmware.com</email>
</author>
<published>2018-09-13T20:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=61b5194808f405fbf901f7c8280333cad0ec9768'/>
<id>urn:sha1:61b5194808f405fbf901f7c8280333cad0ec9768</id>
<content type='text'>
commit a3b92ee6fc171d7c9d9b6b829b7fef169210440c upstream.

Fix a build error due to missing virt_to_phys()

Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Fixes: f0a1bf29d821b ("vmw_balloon: fix inflation with batching")
Cc: stable@vger.kernel.org
Cc: Xavier Deguillard &lt;xdeguillard@vmware.com&gt;
Signed-off-by: Nadav Amit &lt;namit@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mei: bus: type promotion bug in mei_nfc_if_version()</title>
<updated>2018-09-26T06:39:43+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-07-11T12:29:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d6c9bc66491803a802b84d9da091ef2261ba637b'/>
<id>urn:sha1:d6c9bc66491803a802b84d9da091ef2261ba637b</id>
<content type='text'>
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: &lt;stable@vger.kernel.org&gt;
Fixes: 582ab27a063a ("mei: bus: fix received data size check in NFC fixup")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>mei: bus: need to unlink client before freeing</title>
<updated>2018-09-26T06:39:32+00:00</updated>
<author>
<name>Tomas Winkler</name>
<email>tomas.winkler@intel.com</email>
</author>
<published>2018-08-27T19:40:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f5f0f2ad7099ccc632b165231122b4263bef80e7'/>
<id>urn:sha1:f5f0f2ad7099ccc632b165231122b4263bef80e7</id>
<content type='text'>
commit 34f1166afd67f9f48a08c52f36180048908506a4 upstream.

In case a client fails to connect in mei_cldev_enable(), the
caller won't call the mei_cldev_disable leaving the client
in a linked stated. Upon driver unload the client structure
will be freed in  mei_cl_bus_dev_release(), leaving a stale pointer
on a fail_list.  This will eventually end up in crash
during power down flow in mei_cl_set_disonnected().

RIP:  mei_cl_set_disconnected+0x5/0x260[mei]
Call trace:
mei_cl_all_disconnect+0x22/0x30
mei_reset+0x194/0x250
__synchronize_hardirq+0x43/0x50
_cond_resched+0x15/0x30
mei_me_intr_clear+0x20/0x100
mei_stop+0x76/0xb0
mei_me_shutdown+0x3f/0x80
pci_device_shutdown+0x34/0x60
kernel_restart+0x0e/0x30

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200455
Fixes: 'c110cdb17148 ("mei: bus: make a client pointer always available")'
Cc: &lt;stable@vger.kernel.org&gt; 4.10+
Tested-by: Georg Müller &lt;georgmueller@gmx.net&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mei: bus: fix hw module get/put balance</title>
<updated>2018-09-26T06:39:32+00:00</updated>
<author>
<name>Tomas Winkler</name>
<email>tomas.winkler@intel.com</email>
</author>
<published>2018-08-27T19:40:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a1a8326f891c751a44c5a4bd487a39e59bb538a8'/>
<id>urn:sha1:a1a8326f891c751a44c5a4bd487a39e59bb538a8</id>
<content type='text'>
commit 69bf5313035926b0b6a6578de4f3168a8f5c19b8 upstream.

In case the device is not connected it doesn't 'get'
hw module and hence should not 'put' it on disable.

Cc: &lt;stable@vger.kernel.org&gt; 4.16+
Fixes:'commit 257355a44b99 ("mei: make module referencing local to the bus.c")'
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200455
Tested-by: Georg Müller &lt;georgmueller@gmx.net&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mei: ignore not found client in the enumeration</title>
<updated>2018-09-26T06:39:32+00:00</updated>
<author>
<name>Alexander Usyskin</name>
<email>alexander.usyskin@intel.com</email>
</author>
<published>2018-08-06T14:47:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=93f03d6dcbb6bb19618e07e1db9b5805bbb2b436'/>
<id>urn:sha1:93f03d6dcbb6bb19618e07e1db9b5805bbb2b436</id>
<content type='text'>
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: &lt;stable@vger.kernel.org&gt;
Reported-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>misc: hmc6352: fix potential Spectre v1</title>
<updated>2018-09-26T06:39:31+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2018-08-15T15:50:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9ed3ad68de71f17d0a1102d07fc4fa84b03195a3'/>
<id>urn:sha1:9ed3ad68de71f17d0a1102d07fc4fa84b03195a3</id>
<content type='text'>
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&amp;m=152449131114778&amp;w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>misc: ibmvsm: Fix wrong assignment of return code</title>
<updated>2018-09-26T06:39:31+00:00</updated>
<author>
<name>Bryant G. Ly</name>
<email>bryantly@linux.ibm.com</email>
</author>
<published>2018-08-06T13:31:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=094302a07e8952ddcb8cc8d7a047e29a1843d150'/>
<id>urn:sha1:094302a07e8952ddcb8cc8d7a047e29a1843d150</id>
<content type='text'>
commit c55e9318871cd06e4aa10f5023cc2dcdfbb08577 upstream.

Currently the assignment is flipped and rc is always 0.

Signed-off-by: Bryant G. Ly &lt;bryantly@linux.ibm.com&gt;
Fixes: 0eca353e7ae7 ("misc: IBM Virtual Management Channel Driver (VMC)")
Reviewed-by: Bradley Warrum &lt;bwarrum@us.ibm.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>misc: ti-st: Fix memory leak in the error path of probe()</title>
<updated>2018-09-19T20:41:26+00:00</updated>
<author>
<name>Anton Vasilyev</name>
<email>vasilyev@ispras.ru</email>
</author>
<published>2018-07-27T15:45:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=baec9ce83ad583a9a353d32d7089e0a54ed22aeb'/>
<id>urn:sha1:baec9ce83ad583a9a353d32d7089e0a54ed22aeb</id>
<content type='text'>
[ 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 &lt;vasilyev@ispras.ru&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: mic: SCIF Fix scif_get_new_port() error handling</title>
<updated>2018-09-19T20:41:24+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-08-02T08:42:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c6fe801568288436849231aa1431843c0cef0642'/>
<id>urn:sha1:c6fe801568288436849231aa1431843c0cef0642</id>
<content type='text'>
[ 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 &gt;= 0 on success.

Fixes: e9089f43c9a7 ("misc: mic: SCIF open close bind and listen APIs")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vmw_balloon: fix VMCI use when balloon built into kernel</title>
<updated>2018-09-09T08:32:35+00:00</updated>
<author>
<name>Nadav Amit</name>
<email>namit@vmware.com</email>
</author>
<published>2018-06-19T23:00:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ad7a3f8c456ffc755469056699a685ebf1a188b7'/>
<id>urn:sha1:ad7a3f8c456ffc755469056699a685ebf1a188b7</id>
<content type='text'>
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 &lt;xdeguillard@vmware.com&gt;
Signed-off-by: Nadav Amit &lt;namit@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
