linux-stable.git/drivers/net/wireless, branch v3.16.48

brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()

2017-09-15T17:30:18+00:00

commit 8f44c9a41386729fea410e688959ddaa9d51be7c upstream.

The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280.  However, the action_frame->data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.

	memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
	       le16_to_cpu(action_frame->len));

Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
Reported-by: "freenerguo(郭大兴)" 
Signed-off-by: Arend van Spriel 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

ath9k_htc: add device ID for Toshiba WLM-20U2/GN-1080

2017-08-26T01:14:48+00:00

commit aea57edf80c6e96d6dc24757599396af99c02b19 upstream.

This device is available under different marketing names:
WLM-20U2 - Wireless USB Dongle for Toshiba TVs
GN-1080 - Wireless LAN Module for Toshiba MFPs.

Signed-off-by: Alexander Tsoy 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

mwifiex: pcie: fix cmd_buf use-after-free in remove/reset

2017-08-26T01:14:36+00:00

commit 3c8cb9ad032d737b874e402c59eb51e3c991a144 upstream.

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 > /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] [] dump_backtrace+0x0/0x190
[  205.808415] [] show_stack+0x20/0x28
[  205.813506] [] dump_stack+0xa4/0xcc
[  205.818598] [] print_trailer+0x158/0x168
[  205.824120] [] object_err+0x4c/0x5c
[  205.829210] [] kasan_report+0x334/0x500
[  205.834641] [] check_memory_region+0x20/0x14c
[  205.840593] [] __asan_loadN+0x14/0x1c
[  205.845879] [] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie]
[  205.854282] [] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie]
[  205.862421] [] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie]
[  205.870302] [] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie]
[  205.877736] [] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
[  205.884658] [] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[  205.892446] [] pci_reset_notify+0x5c/0x6c
[  205.898048] [] pci_dev_save_and_disable+0x24/0x6c
[  205.904350] [] pci_reset_function+0x30/0x7c
[  205.910134] [] reset_store+0x68/0x98
[  205.915312] [] dev_attr_store+0x54/0x60
[  205.920750] [] sysfs_kf_write+0x9c/0xb0
[  205.926182] [] kernfs_fop_write+0x184/0x1f8
[  205.931963] [] __vfs_write+0x6c/0x17c
[  205.937221] [] vfs_write+0xf0/0x1c4
[  205.942310] [] SyS_write+0x78/0xd8
[  205.947312] [] 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")
Signed-off-by: Brian Norris 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

ath9k: off by one in ath9k_hw_nvram_read_array()

2017-08-26T01:14:36+00:00

commit b7dcf68f383a05567bd16a390907b67022a62d3d upstream.

The > should be >= or we read one space beyond the end of the array.

Fixes: ab5c4f71d8c7 ("ath9k: allow to load EEPROM content via firmware API")
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ath9k_htc: fix NULL-deref at probe

2017-08-26T01:14:28+00:00

commit ebeb36670ecac36c179b5fb5d5c88ff03ba191ec upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
Signed-off-by: Johan Hovold 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

zd1211rw: fix NULL-deref at probe

2017-08-26T01:14:25+00:00

commit ca260ece6a57dc7d751e0685f51fa2c55d851873 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device into WLAN device")
Cc: Daniel Drake 
Signed-off-by: Johan Hovold 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device

2017-08-26T01:14:24+00:00

commit 16ff1fb0e32f76a5d285a6f23b82d21aa52813c6 upstream.

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=1eda ProdID=2315 Rev=01.08
S:  Manufacturer=ATHEROS
S:  Product=USB2.0 WLAN
S:  SerialNumber=12345
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)

Signed-off-by: Dmitry Tunin 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

ath9k_htc: Add new USB ID

2017-08-26T01:14:24+00:00

commit 0088d27b78f2c0118aee82923269518616481ea0 upstream.

This device is a dongle made by Philips to enhance their TVs with wireless capabilities,
but works flawlessly on any upstream kernel, provided that the ath9k_htc module is attached to it.
It's correctly recognized by lsusb as "0471:209e Philips (or NXP) PTA01 Wireless Adapter" and the
patch has been tested on real hardware.

Signed-off-by: Leon Nardella 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

include/linux/kernel.h: change abs() macro so it uses consistent return type

2017-07-18T17:40:28+00:00

commit 8f57e4d930d48217268315898212518d4d3e0773 upstream.

Rewrite abs() so that its return type does not depend on the
architecture and no unexpected type conversion happen inside of it.  The
only conversion is from unsigned to signed type.  char is left as a
return type but treated as a signed type regradless of it's actual
signedness.

With the old version, int arguments were promoted to long and depending
on architecture a long argument might result in s64 or long return type
(which may or may not be the same).

This came after some back and forth with Nicolas.  The current macro has
different return type (for the same input type) depending on
architecture which might be midly iritating.

An alternative version would promote to int like so:

	#define abs(x)	__abs_choose_expr(x, long long,			\
			__abs_choose_expr(x, long,			\
			__builtin_choose_expr(				\
				sizeof(x) <= sizeof(int),		\
				({ int __x = (x); __x<0?-__x:__x; }),	\
				((void)0))))

I have no preference but imagine Linus might.  :] Nicolas argument against
is that promoting to int causes iconsistent behaviour:

	int main(void) {
		unsigned short a = 0, b = 1, c = a - b;
		unsigned short d = abs(a - b);
		unsigned short e = abs(c);
		printf("%u %u\n", d, e);  // prints: 1 65535
	}

Then again, no sane person expects consistent behaviour from C integer
arithmetic.  ;)

Note:

  __builtin_types_compatible_p(unsigned char, char) is always false, and
  __builtin_types_compatible_p(signed char, char) is also always false.

Signed-off-by: Michal Nazarewicz 
Reviewed-by: Nicolas Pitre 
Cc: Srinivas Pandruvada 
Cc: Wey-Yi Guy 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

ath9k: use correct OTP register offsets for the AR9340 and AR9550

2017-06-05T20:17:09+00:00

commit c9f1e32600816d695f817477d56490bfc2ba43c6 upstream.

This patch fixes the OTP register definitions for the AR934x and AR9550
WMAC SoC.

Previously, the ath9k driver was unable to initialize the integrated
WMAC on an Aerohive AP121:

| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: Unable to initialize hardware; initialization status: -5
| ath9k ar934x_wmac: failed to initialize device
| ath9k: probe of ar934x_wmac failed with error -5

It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA
definitions contain a typo.

Cc: Gabor Juhos 
Fixes: add295a4afbdf5852d0 "ath9k: use correct OTP register offsets for AR9550"
Signed-off-by: Christian Lamparter 
Signed-off-by: Chris Blake 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings