<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.14.86</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.86</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.86'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-12-05T18:41:26+00:00</updated>
<entry>
<title>binder: fix race that allows malicious free of live buffer</title>
<updated>2018-12-05T18:41:26+00:00</updated>
<author>
<name>Todd Kjos</name>
<email>tkjos@android.com</email>
</author>
<published>2018-11-06T23:55:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd6cc33d0775b0d902906d88dd05cc1a2a059f8d'/>
<id>urn:sha1:fd6cc33d0775b0d902906d88dd05cc1a2a059f8d</id>
<content type='text'>
commit 7bada55ab50697861eee6bb7d60b41e68a961a9c upstream.

Malicious code can attempt to free buffers using the BC_FREE_BUFFER
ioctl to binder. There are protections against a user freeing a buffer
while in use by the kernel, however there was a window where
BC_FREE_BUFFER could be used to free a recently allocated buffer that
was not completely initialized. This resulted in a use-after-free
detected by KASAN with a malicious test program.

This window is closed by setting the buffer's allow_user_free attribute
to 0 when the buffer is allocated or when the user has previously freed
it instead of waiting for the caller to set it. The problem was that
when the struct buffer was recycled, allow_user_free was stale and set
to 1 allowing a free to go through.

Signed-off-by: Todd Kjos &lt;tkjos@google.com&gt;
Acked-by: Arve Hjønnevåg &lt;arve@android.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt; # 4.14
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>misc: mic/scif: fix copy-paste error in scif_create_remote_lookup</title>
<updated>2018-12-05T18:41:26+00:00</updated>
<author>
<name>YueHaibing</name>
<email>yuehaibing@huawei.com</email>
</author>
<published>2018-11-14T01:57:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f7d33988bd923310934c8481a2e68b53f716df13'/>
<id>urn:sha1:f7d33988bd923310934c8481a2e68b53f716df13</id>
<content type='text'>
commit 6484a677294aa5d08c0210f2f387ebb9be646115 upstream.

gcc '-Wunused-but-set-variable' warning:

drivers/misc/mic/scif/scif_rma.c: In function 'scif_create_remote_lookup':
drivers/misc/mic/scif/scif_rma.c:373:25: warning:
 variable 'vmalloc_num_pages' set but not used [-Wunused-but-set-variable]

'vmalloc_num_pages' should be used to determine if the address is
within the vmalloc range.

Fixes: ba612aa8b487 ("misc: mic: SCIF memory registration and unregistration")
Signed-off-by: YueHaibing &lt;yuehaibing@huawei.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>Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()</title>
<updated>2018-12-05T18:41:26+00:00</updated>
<author>
<name>Dexuan Cui</name>
<email>decui@microsoft.com</email>
</author>
<published>2018-11-26T02:29:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c44b197448dfb8bef4fa9cab92b7a73153a6f76'/>
<id>urn:sha1:3c44b197448dfb8bef4fa9cab92b7a73153a6f76</id>
<content type='text'>
commit eceb05965489784f24bbf4d61ba60e475a983016 upstream.

This is a longstanding issue: if the vmbus upper-layer drivers try to
consume too many GPADLs, the host may return with an error
0xC0000044 (STATUS_QUOTA_EXCEEDED), but currently we forget to check
the creation_status, and hence we can pass an invalid GPADL handle
into the OPEN_CHANNEL message, and get an error code 0xc0000225 in
open_info-&gt;response.open_result.status, and finally we hang in
vmbus_open() -&gt; "goto error_free_info" -&gt; vmbus_teardown_gpadl().

With this patch, we can exit gracefully on STATUS_QUOTA_EXCEEDED.

Cc: Stephen Hemminger &lt;sthemmin@microsoft.com&gt;
Cc: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Cc: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio:st_magn: Fix enable device after trigger</title>
<updated>2018-12-05T18:41:26+00:00</updated>
<author>
<name>Martin Kelly</name>
<email>martin@martingkelly.com</email>
</author>
<published>2018-10-29T03:18:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d08c62878fe2040e2cbc70554f86c54895a9f708'/>
<id>urn:sha1:d08c62878fe2040e2cbc70554f86c54895a9f708</id>
<content type='text'>
commit fe5192ac81ad0d4dfe1395d11f393f0513c15f7f upstream.

Currently, we enable the device before we enable the device trigger. At
high frequencies, this can cause interrupts that don't yet have a poll
function associated with them and are thus treated as spurious. At high
frequencies with level interrupts, this can even cause an interrupt storm
of repeated spurious interrupts (~100,000 on my Beagleboard with the
LSM9DS1 magnetometer). If these repeat too much, the interrupt will get
disabled and the device will stop functioning.

To prevent these problems, enable the device prior to enabling the device
trigger, and disable the divec prior to disabling the trigger. This means
there's no window of time during which the device creates interrupts but we
have no trigger to answer them.

Fixes: 90efe055629 ("iio: st_sensors: harden interrupt handling")
Signed-off-by: Martin Kelly &lt;martin@martingkelly.com&gt;
Tested-by: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"</title>
<updated>2018-12-05T18:41:26+00:00</updated>
<author>
<name>Felipe Balbi</name>
<email>felipe.balbi@linux.intel.com</email>
</author>
<published>2018-11-19T06:34:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f1a4876f0435dc43fc55f42bd30763de5e5ef9ec'/>
<id>urn:sha1:f1a4876f0435dc43fc55f42bd30763de5e5ef9ec</id>
<content type='text'>
commit 38317f5c0f2faae5110854f36edad810f841d62f upstream.

This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3.

Turns out that commit is wrong. Host controllers are allowed to use
Clear Feature HALT as means to sync data toggle between host and
periperal.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series</title>
<updated>2018-12-05T18:41:26+00:00</updated>
<author>
<name>Michael Niewöhner</name>
<email>linux@mniewoehner.de</email>
</author>
<published>2018-11-25T16:57:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b7456f46ff957a3f04b3658a8d71b645d8cf172'/>
<id>urn:sha1:2b7456f46ff957a3f04b3658a8d71b645d8cf172</id>
<content type='text'>
commit effd14f66cc1ef6701a19c5a56e39c35f4d395a5 upstream.

Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to
function correctly. This fixes a but where double pressing numlock locks
up the device completely with need to replug the keyboard.

Signed-off-by: Michael Niewöhner &lt;linux@mniewoehner.de&gt;
Tested-by: Michael Niewöhner &lt;linux@mniewoehner.de&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: usb-storage: Add new IDs to ums-realtek</title>
<updated>2018-12-05T18:41:25+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2018-11-23T08:42:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=403a2001bd795c43f59a5dd6695273fdfe0a3dcf'/>
<id>urn:sha1:403a2001bd795c43f59a5dd6695273fdfe0a3dcf</id>
<content type='text'>
commit a84a1bcc992f0545a51d2e120b8ca2ef20e2ea97 upstream.

There are two new Realtek card readers require ums-realtek to work
correctly.

Add the new IDs to support them.

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>staging: rtl8723bs: Add missing return for cfg80211_rtw_get_station</title>
<updated>2018-12-05T18:41:25+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2018-11-09T05:30:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74abe400e12b45f871c98c99f0f65521cc0c8ca6'/>
<id>urn:sha1:74abe400e12b45f871c98c99f0f65521cc0c8ca6</id>
<content type='text'>
commit 8561fb31a1f9594e2807681f5c0721894e367f19 upstream.

With Androidx86 8.1, wificond returns "failed to get
nl80211_sta_info_tx_failed" and wificondControl returns "Invalid signal
poll result from wificond". The fix is to OR sinfo-&gt;filled with
BIT_ULL(NL80211_STA_INFO_TX_FAILED).

This missing bit is apparently not needed with NetworkManager, but it
does no harm in that case.

Reported-and-Tested-by: youling257 &lt;youling257@gmail.com&gt;
Cc: linux-wireless@vger.kernel.org
Cc: youling257 &lt;youling257@gmail.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>staging: vchiq_arm: fix compat VCHIQ_IOC_AWAIT_COMPLETION</title>
<updated>2018-12-05T18:41:25+00:00</updated>
<author>
<name>Ben Wolsieffer</name>
<email>benwolsieffer@gmail.com</email>
</author>
<published>2018-11-03T23:32:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ca0908ddcd303d5e91982c6e5a91ad3d99cc99b6'/>
<id>urn:sha1:ca0908ddcd303d5e91982c6e5a91ad3d99cc99b6</id>
<content type='text'>
commit 5a96b2d38dc054c0bbcbcd585b116566cbd877fe upstream.

The compatibility ioctl wrapper for VCHIQ_IOC_AWAIT_COMPLETION assumes that
the native ioctl always uses a message buffer and decrements msgbufcount.
Certain message types do not use a message buffer and in this case
msgbufcount is not decremented, and completion-&gt;header for the message is
NULL. Because the wrapper unconditionally decrements msgbufcount, the
calling process may assume that a message buffer has been used even when
it has not.

This results in a memory leak in the userspace code that interfaces with
this driver. When msgbufcount is decremented, the userspace code assumes
that the buffer can be freed though the reference in completion-&gt;header,
which cannot happen when the reference is NULL.

This patch causes the wrapper to only decrement msgbufcount when the
native ioctl decrements it. Note that we cannot simply copy the native
ioctl's value of msgbufcount, because the wrapper only retrieves messages
from the native ioctl one at a time, while userspace may request multiple
messages.

See https://github.com/raspberrypi/linux/pull/2703 for more discussion of
this patch.

Fixes: 5569a1260933 ("staging: vchiq_arm: Add compatibility wrappers for ioctls")
Signed-off-by: Ben Wolsieffer &lt;benwolsieffer@gmail.com&gt;
Acked-by: Stefan Wahren &lt;stefan.wahren@i2se.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>dmaengine: at_hdmac: fix module unloading</title>
<updated>2018-12-05T18:41:25+00:00</updated>
<author>
<name>Richard Genoud</name>
<email>richard.genoud@gmail.com</email>
</author>
<published>2018-11-27T16:06:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39c49a757d7c3e27d3bfabd1e102e9544372e103'/>
<id>urn:sha1:39c49a757d7c3e27d3bfabd1e102e9544372e103</id>
<content type='text'>
commit 77e75fda94d2ebb86aa9d35fb1860f6395bf95de upstream.

of_dma_controller_free() was not called on module onloading.
This lead to a soft lockup:
watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
Modules linked in: at_hdmac [last unloaded: at_hdmac]
when of_dma_request_slave_channel() tried to call ofdma-&gt;of_dma_xlate().

Cc: stable@vger.kernel.org
Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding")
Acked-by: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Signed-off-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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