<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers, branch v4.1.41</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>xc2028: Fix use-after-free bug properly</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-11-17T09:49:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=afeb39160249eed5b585b4e9c8227351725b29fd'/>
<id>afeb39160249eed5b585b4e9c8227351725b29fd</id>
<content type='text'>
[ Upstream commit 22a1e7783e173ab3d86018eb590107d68df46c11 ]

The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.

However, it's clearing the wrong pointer; it sets NULL to
priv-&gt;ctrl.fname, but it's anyway overwritten by the next line
memcpy(&amp;priv-&gt;ctrl, p, sizeof(priv-&gt;ctrl)).

OTOH, the actual code accessing the freed string is the strcmp() call
with priv-&gt;fname:
	if (!firmware_name[0] &amp;&amp; p-&gt;fname &amp;&amp;
	    priv-&gt;fname &amp;&amp; strcmp(p-&gt;fname, priv-&gt;fname))
		free_firmware(priv);

where priv-&gt;fname points to the previous file name, and this was
already freed by kfree().

For fixing the bug properly, this patch does the following:

- Keep the copy of firmware file name in only priv-&gt;fname,
  priv-&gt;ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly

Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 22a1e7783e173ab3d86018eb590107d68df46c11 ]

The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.

However, it's clearing the wrong pointer; it sets NULL to
priv-&gt;ctrl.fname, but it's anyway overwritten by the next line
memcpy(&amp;priv-&gt;ctrl, p, sizeof(priv-&gt;ctrl)).

OTOH, the actual code accessing the freed string is the strcmp() call
with priv-&gt;fname:
	if (!firmware_name[0] &amp;&amp; p-&gt;fname &amp;&amp;
	    priv-&gt;fname &amp;&amp; strcmp(p-&gt;fname, priv-&gt;fname))
		free_firmware(priv);

where priv-&gt;fname points to the previous file name, and this was
already freed by kfree().

For fixing the bug properly, this patch does the following:

- Keep the copy of firmware file name in only priv-&gt;fname,
  priv-&gt;ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly

Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: proximity: as3935: fix as3935_write</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Matt Ranostay</name>
<email>matt.ranostay@konsulko.com</email>
</author>
<published>2017-04-14T06:21:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5eef36af59740aa26f9a39ff8124134ec3e0c4ef'/>
<id>5eef36af59740aa26f9a39ff8124134ec3e0c4ef</id>
<content type='text'>
[ Upstream commit 84ca8e364acb26aba3292bc113ca8ed4335380fd ]

AS3935_WRITE_DATA macro bit is incorrect and the actual write
sequence is two leading zeros.

Cc: George McCollister &lt;george.mccollister@gmail.com&gt;
Signed-off-by: Matt Ranostay &lt;matt.ranostay@konsulko.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 84ca8e364acb26aba3292bc113ca8ed4335380fd ]

AS3935_WRITE_DATA macro bit is incorrect and the actual write
sequence is two leading zeros.

Cc: George McCollister &lt;george.mccollister@gmail.com&gt;
Signed-off-by: Matt Ranostay &lt;matt.ranostay@konsulko.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: dac: ad7303: fix channel description</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Pavel Roskin</name>
<email>plroskin@gmail.com</email>
</author>
<published>2017-04-13T21:54:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=953334de0819acba9cfebb3a7fd190a9b7d6b7e5'/>
<id>953334de0819acba9cfebb3a7fd190a9b7d6b7e5</id>
<content type='text'>
[ Upstream commit ce420fd4251809b4c3119b3b20c8b13bd8eba150 ]

realbits, storagebits and shift should be numbers, not ASCII characters.

Signed-off-by: Pavel Roskin &lt;plroskin@gmail.com&gt;
Reviewed-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ce420fd4251809b4c3119b3b20c8b13bd8eba150 ]

realbits, storagebits and shift should be numbers, not ASCII characters.

Signed-off-by: Pavel Roskin &lt;plroskin@gmail.com&gt;
Reviewed-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: pcie: fix cmd_buf use-after-free in remove/reset</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2017-04-14T21:51:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=60e2e499e37da15bf6d81a9c5f1e76e750006850'/>
<id>60e2e499e37da15bf6d81a9c5f1e76e750006850</id>
<content type='text'>
[ Upstream commit 3c8cb9ad032d737b874e402c59eb51e3c991a144 ]

Command buffers (skb's) are allocated by the main driver, and freed upon
the last use. That last use is often in mwifiex_free_cmd_buffer(). In
the meantime, if the command buffer gets used by the PCI driver, we map
it as DMA-able, and store the mapping information in the 'cb' memory.

However, if a command was in-flight when resetting the device (and
therefore was still mapped), we don't get a chance to unmap this memory
until after the core has cleaned up its command handling.

Let's keep a refcount within the PCI driver, so we ensure the memory
only gets freed after we've finished unmapping it.

Noticed by KASAN when forcing a reset via:

  echo 1 &gt; /sys/bus/pci/.../reset

The same code path can presumably be exercised in remove() and
shutdown().

[  205.390377] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex...
[  205.400393] ==================================================================
[  205.407719] BUG: KASAN: use-after-free in mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr ffffffc0ad471b28
[  205.419040] Read of size 16 by task bash/1913
[  205.423421] =============================================================================
[  205.431625] BUG skbuff_head_cache (Tainted: G    B          ): kasan: bad access detected
[  205.439815] -----------------------------------------------------------------------------
[  205.439815]
[  205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913
[  205.456709] 	alloc_debug_processing+0x124/0x178
[  205.461282] 	___slab_alloc.constprop.58+0x528/0x608
[  205.466196] 	__slab_alloc.isra.54.constprop.57+0x44/0x54
[  205.471542] 	kmem_cache_alloc+0xcc/0x278
[  205.475497] 	__build_skb+0x48/0x114
[  205.479019] 	__netdev_alloc_skb+0xe0/0x170
[  205.483244] 	mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex]
[  205.488759] 	mwifiex_init_fw+0x40/0x6cc [mwifiex]
[  205.493584] 	_mwifiex_fw_dpc+0x158/0x520 [mwifiex]
[  205.498491] 	mwifiex_reinit_sw+0x2c4/0x398 [mwifiex]
[  205.503510] 	mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie]
[  205.509643] 	pci_reset_notify+0x5c/0x6c
[  205.513519] 	pci_reset_function+0x6c/0x7c
[  205.517567] 	reset_store+0x68/0x98
[  205.521003] 	dev_attr_store+0x54/0x60
[  205.524705] 	sysfs_kf_write+0x9c/0xb0
[  205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913
[  205.535064] 	free_debug_processing+0x264/0x370
[  205.539550] 	__slab_free+0x84/0x40c
[  205.543075] 	kmem_cache_free+0x1c8/0x2a0
[  205.547030] 	__kfree_skb+0xb0/0xbc
[  205.550465] 	consume_skb+0x164/0x178
[  205.554079] 	__dev_kfree_skb_any+0x58/0x64
[  205.558304] 	mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex]
[  205.563817] 	mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex]
[  205.569164] 	mwifiex_shutdown_sw+0x178/0x310 [mwifiex]
[  205.574353] 	mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[  205.580398] 	pci_reset_notify+0x5c/0x6c
[  205.584274] 	pci_dev_save_and_disable+0x24/0x6c
[  205.588837] 	pci_reset_function+0x30/0x7c
[  205.592885] 	reset_store+0x68/0x98
[  205.596324] 	dev_attr_store+0x54/0x60
[  205.600017] 	sysfs_kf_write+0x9c/0xb0
...
[  205.800488] Call trace:
[  205.802980] [&lt;ffffffc00020a69c&gt;] dump_backtrace+0x0/0x190
[  205.808415] [&lt;ffffffc00020a96c&gt;] show_stack+0x20/0x28
[  205.813506] [&lt;ffffffc0005d020c&gt;] dump_stack+0xa4/0xcc
[  205.818598] [&lt;ffffffc0003be44c&gt;] print_trailer+0x158/0x168
[  205.824120] [&lt;ffffffc0003be5f0&gt;] object_err+0x4c/0x5c
[  205.829210] [&lt;ffffffc0003c45bc&gt;] kasan_report+0x334/0x500
[  205.834641] [&lt;ffffffc0003c3994&gt;] check_memory_region+0x20/0x14c
[  205.840593] [&lt;ffffffc0003c3b14&gt;] __asan_loadN+0x14/0x1c
[  205.845879] [&lt;ffffffbffc46171c&gt;] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie]
[  205.854282] [&lt;ffffffbffc461864&gt;] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie]
[  205.862421] [&lt;ffffffbffc462028&gt;] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie]
[  205.870302] [&lt;ffffffbffc4620d4&gt;] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie]
[  205.877736] [&lt;ffffffbffc1397a8&gt;] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
[  205.884658] [&lt;ffffffbffc4606b4&gt;] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[  205.892446] [&lt;ffffffc000635f54&gt;] pci_reset_notify+0x5c/0x6c
[  205.898048] [&lt;ffffffc00063a044&gt;] pci_dev_save_and_disable+0x24/0x6c
[  205.904350] [&lt;ffffffc00063cf0c&gt;] pci_reset_function+0x30/0x7c
[  205.910134] [&lt;ffffffc000641118&gt;] reset_store+0x68/0x98
[  205.915312] [&lt;ffffffc000771588&gt;] dev_attr_store+0x54/0x60
[  205.920750] [&lt;ffffffc00046f53c&gt;] sysfs_kf_write+0x9c/0xb0
[  205.926182] [&lt;ffffffc00046dfb0&gt;] kernfs_fop_write+0x184/0x1f8
[  205.931963] [&lt;ffffffc0003d64f4&gt;] __vfs_write+0x6c/0x17c
[  205.937221] [&lt;ffffffc0003d7164&gt;] vfs_write+0xf0/0x1c4
[  205.942310] [&lt;ffffffc0003d7da0&gt;] SyS_write+0x78/0xd8
[  205.947312] [&lt;ffffffc000204634&gt;] el0_svc_naked+0x24/0x28
...
[  205.998268] ==================================================================

This bug has been around in different forms for a while. It was sort of
noticed in commit 955ab095c51a ("mwifiex: Do not kfree cmd buf while
unregistering PCIe"), but it just fixed the double-free, without
acknowledging the potential for use-after-free.

Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3c8cb9ad032d737b874e402c59eb51e3c991a144 ]

Command buffers (skb's) are allocated by the main driver, and freed upon
the last use. That last use is often in mwifiex_free_cmd_buffer(). In
the meantime, if the command buffer gets used by the PCI driver, we map
it as DMA-able, and store the mapping information in the 'cb' memory.

However, if a command was in-flight when resetting the device (and
therefore was still mapped), we don't get a chance to unmap this memory
until after the core has cleaned up its command handling.

Let's keep a refcount within the PCI driver, so we ensure the memory
only gets freed after we've finished unmapping it.

Noticed by KASAN when forcing a reset via:

  echo 1 &gt; /sys/bus/pci/.../reset

The same code path can presumably be exercised in remove() and
shutdown().

[  205.390377] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex...
[  205.400393] ==================================================================
[  205.407719] BUG: KASAN: use-after-free in mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr ffffffc0ad471b28
[  205.419040] Read of size 16 by task bash/1913
[  205.423421] =============================================================================
[  205.431625] BUG skbuff_head_cache (Tainted: G    B          ): kasan: bad access detected
[  205.439815] -----------------------------------------------------------------------------
[  205.439815]
[  205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913
[  205.456709] 	alloc_debug_processing+0x124/0x178
[  205.461282] 	___slab_alloc.constprop.58+0x528/0x608
[  205.466196] 	__slab_alloc.isra.54.constprop.57+0x44/0x54
[  205.471542] 	kmem_cache_alloc+0xcc/0x278
[  205.475497] 	__build_skb+0x48/0x114
[  205.479019] 	__netdev_alloc_skb+0xe0/0x170
[  205.483244] 	mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex]
[  205.488759] 	mwifiex_init_fw+0x40/0x6cc [mwifiex]
[  205.493584] 	_mwifiex_fw_dpc+0x158/0x520 [mwifiex]
[  205.498491] 	mwifiex_reinit_sw+0x2c4/0x398 [mwifiex]
[  205.503510] 	mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie]
[  205.509643] 	pci_reset_notify+0x5c/0x6c
[  205.513519] 	pci_reset_function+0x6c/0x7c
[  205.517567] 	reset_store+0x68/0x98
[  205.521003] 	dev_attr_store+0x54/0x60
[  205.524705] 	sysfs_kf_write+0x9c/0xb0
[  205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913
[  205.535064] 	free_debug_processing+0x264/0x370
[  205.539550] 	__slab_free+0x84/0x40c
[  205.543075] 	kmem_cache_free+0x1c8/0x2a0
[  205.547030] 	__kfree_skb+0xb0/0xbc
[  205.550465] 	consume_skb+0x164/0x178
[  205.554079] 	__dev_kfree_skb_any+0x58/0x64
[  205.558304] 	mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex]
[  205.563817] 	mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex]
[  205.569164] 	mwifiex_shutdown_sw+0x178/0x310 [mwifiex]
[  205.574353] 	mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[  205.580398] 	pci_reset_notify+0x5c/0x6c
[  205.584274] 	pci_dev_save_and_disable+0x24/0x6c
[  205.588837] 	pci_reset_function+0x30/0x7c
[  205.592885] 	reset_store+0x68/0x98
[  205.596324] 	dev_attr_store+0x54/0x60
[  205.600017] 	sysfs_kf_write+0x9c/0xb0
...
[  205.800488] Call trace:
[  205.802980] [&lt;ffffffc00020a69c&gt;] dump_backtrace+0x0/0x190
[  205.808415] [&lt;ffffffc00020a96c&gt;] show_stack+0x20/0x28
[  205.813506] [&lt;ffffffc0005d020c&gt;] dump_stack+0xa4/0xcc
[  205.818598] [&lt;ffffffc0003be44c&gt;] print_trailer+0x158/0x168
[  205.824120] [&lt;ffffffc0003be5f0&gt;] object_err+0x4c/0x5c
[  205.829210] [&lt;ffffffc0003c45bc&gt;] kasan_report+0x334/0x500
[  205.834641] [&lt;ffffffc0003c3994&gt;] check_memory_region+0x20/0x14c
[  205.840593] [&lt;ffffffc0003c3b14&gt;] __asan_loadN+0x14/0x1c
[  205.845879] [&lt;ffffffbffc46171c&gt;] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie]
[  205.854282] [&lt;ffffffbffc461864&gt;] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie]
[  205.862421] [&lt;ffffffbffc462028&gt;] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie]
[  205.870302] [&lt;ffffffbffc4620d4&gt;] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie]
[  205.877736] [&lt;ffffffbffc1397a8&gt;] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
[  205.884658] [&lt;ffffffbffc4606b4&gt;] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[  205.892446] [&lt;ffffffc000635f54&gt;] pci_reset_notify+0x5c/0x6c
[  205.898048] [&lt;ffffffc00063a044&gt;] pci_dev_save_and_disable+0x24/0x6c
[  205.904350] [&lt;ffffffc00063cf0c&gt;] pci_reset_function+0x30/0x7c
[  205.910134] [&lt;ffffffc000641118&gt;] reset_store+0x68/0x98
[  205.915312] [&lt;ffffffc000771588&gt;] dev_attr_store+0x54/0x60
[  205.920750] [&lt;ffffffc00046f53c&gt;] sysfs_kf_write+0x9c/0xb0
[  205.926182] [&lt;ffffffc00046dfb0&gt;] kernfs_fop_write+0x184/0x1f8
[  205.931963] [&lt;ffffffc0003d64f4&gt;] __vfs_write+0x6c/0x17c
[  205.937221] [&lt;ffffffc0003d7164&gt;] vfs_write+0xf0/0x1c4
[  205.942310] [&lt;ffffffc0003d7da0&gt;] SyS_write+0x78/0xd8
[  205.947312] [&lt;ffffffc000204634&gt;] el0_svc_naked+0x24/0x28
...
[  205.998268] ==================================================================

This bug has been around in different forms for a while. It was sort of
noticed in commit 955ab095c51a ("mwifiex: Do not kfree cmd buf while
unregistering PCIe"), but it just fixed the double-free, without
acknowledging the potential for use-after-free.

Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtlwifi: rtl8821ae: setup 8812ae RFE according to device type</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2017-04-17T00:32:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=036ab4111761ca02eb9b99b9db5ca41daaef8c06'/>
<id>036ab4111761ca02eb9b99b9db5ca41daaef8c06</id>
<content type='text'>
[ Upstream commit 46cfa2148e7371c537efff1a1c693e58f523089d ]

Current channel switch implementation sets 8812ae RFE reg value assuming
that device always has type 2.

Extend possible RFE types set and write corresponding reg values.

Source for new code is
http://dlcdnet.asus.com/pub/ASUS/wireless/PCE-AC51/DR_PCE_AC51_20232801152016.zip

Signed-off-by: Maxim Samoylov &lt;max7255@gmail.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt;
Cc: Yan-Hsuan Chuang &lt;yhchuang@realtek.com&gt;
Cc: Pkshih &lt;pkshih@realtek.com&gt;
Cc: Birming Chiu &lt;birming@realtek.com&gt;
Cc: Shaofu &lt;shaofu@realtek.com&gt;
Cc: Steven Ting &lt;steventing@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 46cfa2148e7371c537efff1a1c693e58f523089d ]

Current channel switch implementation sets 8812ae RFE reg value assuming
that device always has type 2.

Extend possible RFE types set and write corresponding reg values.

Source for new code is
http://dlcdnet.asus.com/pub/ASUS/wireless/PCE-AC51/DR_PCE_AC51_20232801152016.zip

Signed-off-by: Maxim Samoylov &lt;max7255@gmail.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt;
Cc: Yan-Hsuan Chuang &lt;yhchuang@realtek.com&gt;
Cc: Pkshih &lt;pkshih@realtek.com&gt;
Cc: Birming Chiu &lt;birming@realtek.com&gt;
Cc: Shaofu &lt;shaofu@realtek.com&gt;
Cc: Steven Ting &lt;steventing@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vfio/type1: Remove locked page accounting workqueue</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2017-04-13T20:10:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=273225634fef092a063010d0eb48232bda2895af'/>
<id>273225634fef092a063010d0eb48232bda2895af</id>
<content type='text'>
[ Upstream commit 0cfef2b7410b64d7a430947e0b533314c4f97153 ]

If the mmap_sem is contented then the vfio type1 IOMMU backend will
defer locked page accounting updates to a workqueue task.  This has a
few problems and depending on which side the user tries to play, they
might be over-penalized for unmaps that haven't yet been accounted or
race the workqueue to enter more mappings than they're allowed.  The
original intent of this workqueue mechanism seems to be focused on
reducing latency through the ioctl, but we cannot do so at the cost
of correctness.  Remove this workqueue mechanism and update the
callers to allow for failure.  We can also now recheck the limit under
write lock to make sure we don't exceed it.

vfio_pin_pages_remote() also now necessarily includes an unwind path
which we can jump to directly if the consecutive page pinning finds
that we're exceeding the user's memory limits.  This avoids the
current lazy approach which does accounting and mapping up to the
fault, only to return an error on the next iteration to unwind the
entire vfio_dma.

Cc: stable@vger.kernel.org
Reviewed-by: Peter Xu &lt;peterx@redhat.com&gt;
Reviewed-by: Kirti Wankhede &lt;kwankhede@nvidia.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0cfef2b7410b64d7a430947e0b533314c4f97153 ]

If the mmap_sem is contented then the vfio type1 IOMMU backend will
defer locked page accounting updates to a workqueue task.  This has a
few problems and depending on which side the user tries to play, they
might be over-penalized for unmaps that haven't yet been accounted or
race the workqueue to enter more mappings than they're allowed.  The
original intent of this workqueue mechanism seems to be focused on
reducing latency through the ioctl, but we cannot do so at the cost
of correctness.  Remove this workqueue mechanism and update the
callers to allow for failure.  We can also now recheck the limit under
write lock to make sure we don't exceed it.

vfio_pin_pages_remote() also now necessarily includes an unwind path
which we can jump to directly if the consecutive page pinning finds
that we're exceeding the user's memory limits.  This avoids the
current lazy approach which does accounting and mapping up to the
fault, only to return an error on the next iteration to unwind the
entire vfio_dma.

Cc: stable@vger.kernel.org
Reviewed-by: Peter Xu &lt;peterx@redhat.com&gt;
Reviewed-by: Kirti Wankhede &lt;kwankhede@nvidia.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: gdm724x: gdm_mux: fix use-after-free on module unload</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-04-26T10:23:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e0b7d5eae185f302b319cd9f7319584b27ed83b2'/>
<id>e0b7d5eae185f302b319cd9f7319584b27ed83b2</id>
<content type='text'>
[ Upstream commit b58f45c8fc301fe83ee28cad3e64686c19e78f1c ]

Make sure to deregister the USB driver before releasing the tty driver
to avoid use-after-free in the USB disconnect callback where the tty
devices are deregistered.

Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Cc: stable &lt;stable@vger.kernel.org&gt;     # 3.12
Cc: Won Kang &lt;wkang77@gmail.com&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b58f45c8fc301fe83ee28cad3e64686c19e78f1c ]

Make sure to deregister the USB driver before releasing the tty driver
to avoid use-after-free in the USB disconnect callback where the tty
devices are deregistered.

Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Cc: stable &lt;stable@vger.kernel.org&gt;     # 3.12
Cc: Won Kang &lt;wkang77@gmail.com&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/ttm: fix use-after-free races in vm fault handling</title>
<updated>2017-06-13T13:29:21+00:00</updated>
<author>
<name>Nicolai Hähnle</name>
<email>nicolai.haehnle@amd.com</email>
</author>
<published>2017-02-18T21:59:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=47655216cdf4666a274f41ef64adfb2b91a0890e'/>
<id>47655216cdf4666a274f41ef64adfb2b91a0890e</id>
<content type='text'>
[ Upstream commit 3089c1df10e2931b1d72d2ffa7d86431084c86b3 ]

The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is released, other tasks are free to
destroy the VMA, which can lead to the BO being freed. Fix two code
paths where that can happen, both related to vm fault retries.

Found via a lock debugging warning which flagged &amp;bo-&gt;wu_mutex as
locked while being destroyed.

Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
Signed-off-by: Nicolai Hähnle &lt;nicolai.haehnle@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3089c1df10e2931b1d72d2ffa7d86431084c86b3 ]

The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is released, other tasks are free to
destroy the VMA, which can lead to the BO being freed. Fix two code
paths where that can happen, both related to vm fault retries.

Found via a lock debugging warning which flagged &amp;bo-&gt;wu_mutex as
locked while being destroyed.

Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
Signed-off-by: Nicolai Hähnle &lt;nicolai.haehnle@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: emxx_udc: remove incorrect __init annotations</title>
<updated>2017-06-13T13:29:20+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-12-16T09:09:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1c370084c6f3ad44e98ab6dfb4ef57ee8a031eaa'/>
<id>1c370084c6f3ad44e98ab6dfb4ef57ee8a031eaa</id>
<content type='text'>
[ Upstream commit 4f3445067d5f78fb8d1970b02610f85c2f377ea4 ]

The probe function is not marked __init, but some other functions
are. This leads to a warning on older compilers (e.g. gcc-4.3),
and can cause executing freed memory when built with those
compilers:

WARNING: drivers/staging/emxx_udc/emxx_udc.o(.text+0x2d78): Section mismatch in reference from the function nbu2ss_drv_probe() to the function .init.text:nbu2ss_drv_contest_init()

This removes the annotations.

Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4f3445067d5f78fb8d1970b02610f85c2f377ea4 ]

The probe function is not marked __init, but some other functions
are. This leads to a warning on older compilers (e.g. gcc-4.3),
and can cause executing freed memory when built with those
compilers:

WARNING: drivers/staging/emxx_udc/emxx_udc.o(.text+0x2d78): Section mismatch in reference from the function nbu2ss_drv_probe() to the function .init.text:nbu2ss_drv_contest_init()

This removes the annotations.

Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: wlan-ng: add missing byte order conversion</title>
<updated>2017-06-13T13:29:20+00:00</updated>
<author>
<name>Igor Pylypiv</name>
<email>igor.pylypiv@gmail.com</email>
</author>
<published>2017-01-31T05:39:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8602853345b73283cd8825cf356b1600b6adfe6a'/>
<id>8602853345b73283cd8825cf356b1600b6adfe6a</id>
<content type='text'>
[ Upstream commit 2c474b8579e9b67ff72b2bcefce9f53c7f4469d4 ]

Conversion macros le16_to_cpu was removed and that caused new sparse warning

sparse output:
drivers/staging/wlan-ng/p80211netdev.c:241:44: warning: incorrect type in argument 2 (different base types)
drivers/staging/wlan-ng/p80211netdev.c:241:44:    expected unsigned short [unsigned] [usertype] fc
drivers/staging/wlan-ng/p80211netdev.c:241:44:    got restricted __le16 [usertype] fc

Fixes: 7ad82572348c ("staging:wlan-ng:Fix sparse warning")
Signed-off-by: Igor Pylypiv &lt;igor.pylypiv@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2c474b8579e9b67ff72b2bcefce9f53c7f4469d4 ]

Conversion macros le16_to_cpu was removed and that caused new sparse warning

sparse output:
drivers/staging/wlan-ng/p80211netdev.c:241:44: warning: incorrect type in argument 2 (different base types)
drivers/staging/wlan-ng/p80211netdev.c:241:44:    expected unsigned short [unsigned] [usertype] fc
drivers/staging/wlan-ng/p80211netdev.c:241:44:    got restricted __le16 [usertype] fc

Fixes: 7ad82572348c ("staging:wlan-ng:Fix sparse warning")
Signed-off-by: Igor Pylypiv &lt;igor.pylypiv@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
