* [PATCH AUTOSEL 4.9 011/114] brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler()
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
If "ret_len" is negative then it could lead to a NULL dereference.
The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
then we don't allocate the "dcmd_buf" buffer. Then we pass "ret_len" to
brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
Most of the functions in that call tree check whether the buffer we pass
is NULL but there are at least a couple places which don't such as
brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd(). We memcpy() to and
from the buffer so it would result in a NULL dereference.
The fix is to change the types so that "ret_len" can't be negative. (If
we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
issue).
Fixes: 1bacb0487d0e ("brcmfmac: replace cfg80211 testmode with vendor command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index 8eff2753abade..d493021f60318 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -35,9 +35,10 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
struct brcmf_if *ifp;
const struct brcmf_vndr_dcmd_hdr *cmdhdr = data;
struct sk_buff *reply;
- int ret, payload, ret_len;
+ unsigned int payload, ret_len;
void *dcmd_buf = NULL, *wr_pointer;
u16 msglen, maxmsglen = PAGE_SIZE - 0x100;
+ int ret;
if (len < sizeof(*cmdhdr)) {
brcmf_err("vendor command too short: %d\n", len);
@@ -65,7 +66,7 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
brcmf_err("oversize return buffer %d\n", ret_len);
ret_len = BRCMF_DCMD_MAXLEN;
}
- payload = max(ret_len, len) + 1;
+ payload = max_t(unsigned int, ret_len, len) + 1;
dcmd_buf = vzalloc(payload);
if (NULL == dcmd_buf)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 016/114] iwlwifi: pcie: don't crash on invalid RX interrupt
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johannes Berg, Luca Coelho, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 30f24eabab8cd801064c5c37589d803cb4341929 ]
If for some reason the device gives us an RX interrupt before we're
ready for it, perhaps during device power-on with misconfigured IRQ
causes mapping or so, we can crash trying to access the queues.
Prevent that by checking that we actually have RXQs and that they
were properly allocated.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index c21f8bd32d08f..25f2a0aceaa21 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1225,10 +1225,15 @@ static void iwl_pcie_rx_handle_rb(struct iwl_trans *trans,
static void iwl_pcie_rx_handle(struct iwl_trans *trans, int queue)
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
- struct iwl_rxq *rxq = &trans_pcie->rxq[queue];
+ struct iwl_rxq *rxq;
u32 r, i, count = 0;
bool emergency = false;
+ if (WARN_ON_ONCE(!trans_pcie->rxq || !trans_pcie->rxq[queue].bd))
+ return;
+
+ rxq = &trans_pcie->rxq[queue];
+
restart:
spin_lock(&rxq->lock);
/* uCode's read index (stored in shared DRAM) indicates the last Rx
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 023/114] mwifiex: prevent an array overflow
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ]
The "rate_index" is only used as an index into the phist_data->rx_rate[]
array in the mwifiex_hist_data_set() function. That array has
MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
debugfs information. The "rate_index" variable comes from the network
skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap
it to prevent an array overflow.
Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/mwifiex/cfp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff22055e54f8..9ddaa767ea747 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -533,5 +533,8 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
rate_index = (rx_rate > MWIFIEX_RATE_INDEX_OFDM0) ?
rx_rate - 1 : rx_rate;
+ if (rate_index >= MWIFIEX_MAX_AC_RX_RATES)
+ rate_index = MWIFIEX_MAX_AC_RX_RATES - 1;
+
return rate_index;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 024/114] net: cw1200: fix a NULL pointer dereference
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kangjie Lu, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: Kangjie Lu <kjlu@umn.edu>
[ Upstream commit 0ed2a005347400500a39ea7c7318f1fea57fb3ca ]
In case create_singlethread_workqueue fails, the fix free the
hardware and returns NULL to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/st/cw1200/main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/st/cw1200/main.c b/drivers/net/wireless/st/cw1200/main.c
index dc478cedbde0d..84624c812a15f 100644
--- a/drivers/net/wireless/st/cw1200/main.c
+++ b/drivers/net/wireless/st/cw1200/main.c
@@ -345,6 +345,11 @@ static struct ieee80211_hw *cw1200_init_common(const u8 *macaddr,
mutex_init(&priv->wsm_cmd_mux);
mutex_init(&priv->conf_mutex);
priv->workqueue = create_singlethread_workqueue("cw1200_wq");
+ if (!priv->workqueue) {
+ ieee80211_free_hw(hw);
+ return NULL;
+ }
+
sema_init(&priv->scan.lock, 1);
INIT_WORK(&priv->scan.work, cw1200_scan_work);
INIT_DELAYED_WORK(&priv->scan.probe_work, cw1200_probe_work);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 025/114] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 09ac2694b0475f96be895848687ebcbba97eeecf ]
Syzkaller report this:
[ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
[ 1213.469530] #PF error: [normal kernel read fault]
[ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
[ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
[ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8
[ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
[ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
[ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
[ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
[ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
[ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
[ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
[ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
[ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
[ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
[ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1213.473514] PKRU: 55555554
[ 1213.473514] Call Trace:
[ 1213.473514] led_trigger_register+0x112/0x3f0
[ 1213.473514] led_trigger_register_simple+0x7a/0x110
[ 1213.473514] ? 0xffffffffc1c10000
[ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb]
[ 1213.473514] do_one_initcall+0xbc/0x47d
[ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] do_init_module+0x1b5/0x547
[ 1213.473514] load_module+0x6405/0x8c10
[ 1213.473514] ? module_frob_arch_sections+0x20/0x20
[ 1213.473514] ? kernel_read_file+0x1e6/0x5d0
[ 1213.473514] ? find_held_lock+0x32/0x1c0
[ 1213.473514] ? cap_capable+0x1ae/0x210
[ 1213.473514] ? __do_sys_finit_module+0x162/0x190
[ 1213.473514] __do_sys_finit_module+0x162/0x190
[ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0
[ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690
[ 1213.473514] ? wait_for_completion+0x370/0x370
[ 1213.473514] ? vfs_write+0x204/0x4a0
[ 1213.473514] ? do_syscall_64+0x18/0x450
[ 1213.473514] do_syscall_64+0x9f/0x450
[ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1213.473514] RIP: 0033:0x462e99
[ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
[ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
[ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
[ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
[ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
[ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
If usb_register failed, no need to call led_trigger_register_simple.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 1264b951463a ("at76c50x-usb: add driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/atmel/at76c50x-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c b/drivers/net/wireless/atmel/at76c50x-usb.c
index 0e180677c7fc5..09dbab464fe19 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -2583,8 +2583,8 @@ static int __init at76_mod_init(void)
if (result < 0)
printk(KERN_ERR DRIVER_NAME
": usb_register failed (status %d)\n", result);
-
- led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
+ else
+ led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
return result;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 026/114] ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev, bpf
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit b2c01aab9646ed8ffb7c549afe55d5349c482425 ]
Syzkaller report this:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 4492 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
RIP: 0010:sysfs_remove_file_ns+0x27/0x70 fs/sysfs/file.c:468
Code: 00 00 00 41 54 55 48 89 fd 53 49 89 d4 48 89 f3 e8 ee 76 9c ff 48 8d 7d 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 2d 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 8b 6d
RSP: 0018:ffff8881e9d9fc00 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffffffff900367e0 RCX: ffffffff81a95952
RDX: 0000000000000006 RSI: ffffc90001405000 RDI: 0000000000000030
RBP: 0000000000000000 R08: fffffbfff1fa22ed R09: fffffbfff1fa22ed
R10: 0000000000000001 R11: fffffbfff1fa22ec R12: 0000000000000000
R13: ffffffffc1abdac0 R14: 1ffff1103d3b3f8b R15: 0000000000000000
FS: 00007fe409dc1700(0000) GS:ffff8881f1200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2d721000 CR3: 00000001e98b6005 CR4: 00000000007606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
sysfs_remove_file include/linux/sysfs.h:519 [inline]
driver_remove_file+0x40/0x50 drivers/base/driver.c:122
pcmcia_remove_newid_file drivers/pcmcia/ds.c:163 [inline]
pcmcia_unregister_driver+0x7d/0x2b0 drivers/pcmcia/ds.c:209
ssb_modexit+0xa/0x1b [ssb]
__do_sys_delete_module kernel/module.c:1018 [inline]
__se_sys_delete_module kernel/module.c:961 [inline]
__x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe409dc0c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe409dc16bc
R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
Modules linked in: ssb(-) 3c59x nvme_core macvlan tap pata_hpt3x3 rt2x00pci null_blk tsc40 pm_notifier_error_inject notifier_error_inject mdio cdc_wdm nf_reject_ipv4 ath9k_common ath9k_hw ath pppox ppp_generic slhc ehci_platform wl12xx wlcore tps6507x_ts ioc4 nf_synproxy_core ide_gd_mod ax25 can_dev iwlwifi can_raw atm tm2_touchkey can_gw can sundance adp5588_keys rt2800mmio rt2800lib rt2x00mmio rt2x00lib eeprom_93cx6 pn533 lru_cache elants_i2c ip_set nfnetlink gameport tipc hampshire nhc_ipv6 nhc_hop nhc_udp nhc_fragment nhc_routing nhc_mobility nhc_dest 6lowpan silead brcmutil nfc mt76_usb mt76 mac80211 iptable_security iptable_raw iptable_mangle iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_gre sit hsr veth vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon vcan bridge stp llc ip6_gre ip6_tunnel tunnel6 tun joydev mousedev serio_raw ide_pci_generic piix floppy ide_core sch_fq_codel ip_tables x_tables ipv6
[last unloaded: 3c59x]
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 3913cbf8011e1c05 ]---
In ssb_modinit, it does not fail SSB init when ssb_host_pcmcia_init failed,
however in ssb_modexit, ssb_host_pcmcia_exit calls pcmcia_unregister_driver
unconditionally, which may tigger a NULL pointer dereference issue as above.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 399500da18f7 ("ssb: pick PCMCIA host code support from b43 driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ssb/bridge_pcmcia_80211.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/ssb/bridge_pcmcia_80211.c b/drivers/ssb/bridge_pcmcia_80211.c
index d70568ea02d53..2ff7d90e166ac 100644
--- a/drivers/ssb/bridge_pcmcia_80211.c
+++ b/drivers/ssb/bridge_pcmcia_80211.c
@@ -113,16 +113,21 @@ static struct pcmcia_driver ssb_host_pcmcia_driver = {
.resume = ssb_host_pcmcia_resume,
};
+static int pcmcia_init_failed;
+
/*
* These are not module init/exit functions!
* The module_pcmcia_driver() helper cannot be used here.
*/
int ssb_host_pcmcia_init(void)
{
- return pcmcia_register_driver(&ssb_host_pcmcia_driver);
+ pcmcia_init_failed = pcmcia_register_driver(&ssb_host_pcmcia_driver);
+
+ return pcmcia_init_failed;
}
void ssb_host_pcmcia_exit(void)
{
- pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
+ if (!pcmcia_init_failed)
+ pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 07/92] brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler()
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
If "ret_len" is negative then it could lead to a NULL dereference.
The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
then we don't allocate the "dcmd_buf" buffer. Then we pass "ret_len" to
brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
Most of the functions in that call tree check whether the buffer we pass
is NULL but there are at least a couple places which don't such as
brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd(). We memcpy() to and
from the buffer so it would result in a NULL dereference.
The fix is to change the types so that "ret_len" can't be negative. (If
we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
issue).
Fixes: 1bacb0487d0e ("brcmfmac: replace cfg80211 testmode with vendor command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/brcm80211/brcmfmac/vendor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/brcm80211/brcmfmac/vendor.c
index 8eff2753abade..d493021f60318 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/vendor.c
@@ -35,9 +35,10 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
struct brcmf_if *ifp;
const struct brcmf_vndr_dcmd_hdr *cmdhdr = data;
struct sk_buff *reply;
- int ret, payload, ret_len;
+ unsigned int payload, ret_len;
void *dcmd_buf = NULL, *wr_pointer;
u16 msglen, maxmsglen = PAGE_SIZE - 0x100;
+ int ret;
if (len < sizeof(*cmdhdr)) {
brcmf_err("vendor command too short: %d\n", len);
@@ -65,7 +66,7 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
brcmf_err("oversize return buffer %d\n", ret_len);
ret_len = BRCMF_DCMD_MAXLEN;
}
- payload = max(ret_len, len) + 1;
+ payload = max_t(unsigned int, ret_len, len) + 1;
dcmd_buf = vzalloc(payload);
if (NULL == dcmd_buf)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 11/92] mac80211/cfg80211: update bss channel on channel switch
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergey Matyukevich, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]
FullMAC STAs have no way to update bss channel after CSA channel switch
completion. As a result, user-space tools may provide inconsistent
channel info. For instance, consider the following two commands:
$ sudo iw dev wlan0 link
$ sudo iw dev wlan0 info
The latter command gets channel info from the hardware, so most probably
its output will be correct. However the former command gets channel info
from scan cache, so its output will contain outdated channel info.
In fact, current bss channel info will not be updated until the
next [re-]connect.
Note that mac80211 STAs have a workaround for this, but it requires
access to internal cfg80211 data, see ieee80211_chswitch_work:
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->csa_chandef.chan;
This patch suggests to convert mac80211 workaround into cfg80211 behavior
and to update current bss channel in cfg80211_ch_switch_notify.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 3 ---
net/wireless/nl80211.c | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ed4fef32b394f..08384dbf426c8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1104,9 +1104,6 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
}
- /* XXX: shouldn't really modify cfg80211-owned data! */
- ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 81013490a99f4..1968998e6c6c2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12788,6 +12788,11 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+ if (wdev->iftype == NL80211_IFTYPE_STATION &&
+ !WARN_ON(!wdev->current_bss))
+ wdev->current_bss->pub.channel = chandef->chan;
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
NL80211_CMD_CH_SWITCH_NOTIFY, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 14/92] mwifiex: prevent an array overflow
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ]
The "rate_index" is only used as an index into the phist_data->rx_rate[]
array in the mwifiex_hist_data_set() function. That array has
MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
debugfs information. The "rate_index" variable comes from the network
skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap
it to prevent an array overflow.
Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mwifiex/cfp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfp.c b/drivers/net/wireless/mwifiex/cfp.c
index 3ddb8ec676ed3..6dd331dfb5179 100644
--- a/drivers/net/wireless/mwifiex/cfp.c
+++ b/drivers/net/wireless/mwifiex/cfp.c
@@ -533,5 +533,8 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
rate_index = (rx_rate > MWIFIEX_RATE_INDEX_OFDM0) ?
rx_rate - 1 : rx_rate;
+ if (rate_index >= MWIFIEX_MAX_AC_RX_RATES)
+ rate_index = MWIFIEX_MAX_AC_RX_RATES - 1;
+
return rate_index;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 15/92] net: cw1200: fix a NULL pointer dereference
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kangjie Lu, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: Kangjie Lu <kjlu@umn.edu>
[ Upstream commit 0ed2a005347400500a39ea7c7318f1fea57fb3ca ]
In case create_singlethread_workqueue fails, the fix free the
hardware and returns NULL to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/cw1200/main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/cw1200/main.c b/drivers/net/wireless/cw1200/main.c
index 0e51e27d2e3f1..317daa968e037 100644
--- a/drivers/net/wireless/cw1200/main.c
+++ b/drivers/net/wireless/cw1200/main.c
@@ -345,6 +345,11 @@ static struct ieee80211_hw *cw1200_init_common(const u8 *macaddr,
mutex_init(&priv->wsm_cmd_mux);
mutex_init(&priv->conf_mutex);
priv->workqueue = create_singlethread_workqueue("cw1200_wq");
+ if (!priv->workqueue) {
+ ieee80211_free_hw(hw);
+ return NULL;
+ }
+
sema_init(&priv->scan.lock, 1);
INIT_WORK(&priv->scan.work, cw1200_scan_work);
INIT_DELAYED_WORK(&priv->scan.probe_work, cw1200_probe_work);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 16/92] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 09ac2694b0475f96be895848687ebcbba97eeecf ]
Syzkaller report this:
[ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
[ 1213.469530] #PF error: [normal kernel read fault]
[ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
[ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
[ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8
[ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
[ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
[ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
[ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
[ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
[ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
[ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
[ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
[ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
[ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
[ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1213.473514] PKRU: 55555554
[ 1213.473514] Call Trace:
[ 1213.473514] led_trigger_register+0x112/0x3f0
[ 1213.473514] led_trigger_register_simple+0x7a/0x110
[ 1213.473514] ? 0xffffffffc1c10000
[ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb]
[ 1213.473514] do_one_initcall+0xbc/0x47d
[ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] do_init_module+0x1b5/0x547
[ 1213.473514] load_module+0x6405/0x8c10
[ 1213.473514] ? module_frob_arch_sections+0x20/0x20
[ 1213.473514] ? kernel_read_file+0x1e6/0x5d0
[ 1213.473514] ? find_held_lock+0x32/0x1c0
[ 1213.473514] ? cap_capable+0x1ae/0x210
[ 1213.473514] ? __do_sys_finit_module+0x162/0x190
[ 1213.473514] __do_sys_finit_module+0x162/0x190
[ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0
[ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690
[ 1213.473514] ? wait_for_completion+0x370/0x370
[ 1213.473514] ? vfs_write+0x204/0x4a0
[ 1213.473514] ? do_syscall_64+0x18/0x450
[ 1213.473514] do_syscall_64+0x9f/0x450
[ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1213.473514] RIP: 0033:0x462e99
[ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
[ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
[ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
[ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
[ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
[ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
If usb_register failed, no need to call led_trigger_register_simple.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 1264b951463a ("at76c50x-usb: add driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/at76c50x-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index dab25136214a4..da14eca2aa2c8 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -2582,8 +2582,8 @@ static int __init at76_mod_init(void)
if (result < 0)
printk(KERN_ERR DRIVER_NAME
": usb_register failed (status %d)\n", result);
-
- led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
+ else
+ led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
return result;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 17/92] ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev, bpf
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit b2c01aab9646ed8ffb7c549afe55d5349c482425 ]
Syzkaller report this:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 4492 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
RIP: 0010:sysfs_remove_file_ns+0x27/0x70 fs/sysfs/file.c:468
Code: 00 00 00 41 54 55 48 89 fd 53 49 89 d4 48 89 f3 e8 ee 76 9c ff 48 8d 7d 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 2d 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 8b 6d
RSP: 0018:ffff8881e9d9fc00 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffffffff900367e0 RCX: ffffffff81a95952
RDX: 0000000000000006 RSI: ffffc90001405000 RDI: 0000000000000030
RBP: 0000000000000000 R08: fffffbfff1fa22ed R09: fffffbfff1fa22ed
R10: 0000000000000001 R11: fffffbfff1fa22ec R12: 0000000000000000
R13: ffffffffc1abdac0 R14: 1ffff1103d3b3f8b R15: 0000000000000000
FS: 00007fe409dc1700(0000) GS:ffff8881f1200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2d721000 CR3: 00000001e98b6005 CR4: 00000000007606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
sysfs_remove_file include/linux/sysfs.h:519 [inline]
driver_remove_file+0x40/0x50 drivers/base/driver.c:122
pcmcia_remove_newid_file drivers/pcmcia/ds.c:163 [inline]
pcmcia_unregister_driver+0x7d/0x2b0 drivers/pcmcia/ds.c:209
ssb_modexit+0xa/0x1b [ssb]
__do_sys_delete_module kernel/module.c:1018 [inline]
__se_sys_delete_module kernel/module.c:961 [inline]
__x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe409dc0c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe409dc16bc
R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
Modules linked in: ssb(-) 3c59x nvme_core macvlan tap pata_hpt3x3 rt2x00pci null_blk tsc40 pm_notifier_error_inject notifier_error_inject mdio cdc_wdm nf_reject_ipv4 ath9k_common ath9k_hw ath pppox ppp_generic slhc ehci_platform wl12xx wlcore tps6507x_ts ioc4 nf_synproxy_core ide_gd_mod ax25 can_dev iwlwifi can_raw atm tm2_touchkey can_gw can sundance adp5588_keys rt2800mmio rt2800lib rt2x00mmio rt2x00lib eeprom_93cx6 pn533 lru_cache elants_i2c ip_set nfnetlink gameport tipc hampshire nhc_ipv6 nhc_hop nhc_udp nhc_fragment nhc_routing nhc_mobility nhc_dest 6lowpan silead brcmutil nfc mt76_usb mt76 mac80211 iptable_security iptable_raw iptable_mangle iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_gre sit hsr veth vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon vcan bridge stp llc ip6_gre ip6_tunnel tunnel6 tun joydev mousedev serio_raw ide_pci_generic piix floppy ide_core sch_fq_codel ip_tables x_tables ipv6
[last unloaded: 3c59x]
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 3913cbf8011e1c05 ]---
In ssb_modinit, it does not fail SSB init when ssb_host_pcmcia_init failed,
however in ssb_modexit, ssb_host_pcmcia_exit calls pcmcia_unregister_driver
unconditionally, which may tigger a NULL pointer dereference issue as above.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 399500da18f7 ("ssb: pick PCMCIA host code support from b43 driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ssb/bridge_pcmcia_80211.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/ssb/bridge_pcmcia_80211.c b/drivers/ssb/bridge_pcmcia_80211.c
index d70568ea02d53..2ff7d90e166ac 100644
--- a/drivers/ssb/bridge_pcmcia_80211.c
+++ b/drivers/ssb/bridge_pcmcia_80211.c
@@ -113,16 +113,21 @@ static struct pcmcia_driver ssb_host_pcmcia_driver = {
.resume = ssb_host_pcmcia_resume,
};
+static int pcmcia_init_failed;
+
/*
* These are not module init/exit functions!
* The module_pcmcia_driver() helper cannot be used here.
*/
int ssb_host_pcmcia_init(void)
{
- return pcmcia_register_driver(&ssb_host_pcmcia_driver);
+ pcmcia_init_failed = pcmcia_register_driver(&ssb_host_pcmcia_driver);
+
+ return pcmcia_init_failed;
}
void ssb_host_pcmcia_exit(void)
{
- pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
+ if (!pcmcia_init_failed)
+ pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 020/114] mac80211/cfg80211: update bss channel on channel switch
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergey Matyukevich, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]
FullMAC STAs have no way to update bss channel after CSA channel switch
completion. As a result, user-space tools may provide inconsistent
channel info. For instance, consider the following two commands:
$ sudo iw dev wlan0 link
$ sudo iw dev wlan0 info
The latter command gets channel info from the hardware, so most probably
its output will be correct. However the former command gets channel info
from scan cache, so its output will contain outdated channel info.
In fact, current bss channel info will not be updated until the
next [re-]connect.
Note that mac80211 STAs have a workaround for this, but it requires
access to internal cfg80211 data, see ieee80211_chswitch_work:
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->csa_chandef.chan;
This patch suggests to convert mac80211 workaround into cfg80211 behavior
and to update current bss channel in cfg80211_ch_switch_notify.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 3 ---
net/wireless/nl80211.c | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 6e0aa296f1346..d787717140e54 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1072,9 +1072,6 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
}
- /* XXX: shouldn't really modify cfg80211-owned data! */
- ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 09a353c6373a8..d6e6293157717 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -14014,6 +14014,11 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+ if (wdev->iftype == NL80211_IFTYPE_STATION &&
+ !WARN_ON(!wdev->current_bss))
+ wdev->current_bss->pub.channel = chandef->chan;
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
NL80211_CMD_CH_SWITCH_NOTIFY, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 038/167] mwifiex: prevent an array overflow
From: Sasha Levin @ 2019-05-22 19:26 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522192842.25858-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ]
The "rate_index" is only used as an index into the phist_data->rx_rate[]
array in the mwifiex_hist_data_set() function. That array has
MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
debugfs information. The "rate_index" variable comes from the network
skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap
it to prevent an array overflow.
Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/mwifiex/cfp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c b/drivers/net/wireless/marvell/mwifiex/cfp.c
index bfe84e55df776..f1522fb1c1e87 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -531,5 +531,8 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
rate_index = (rx_rate > MWIFIEX_RATE_INDEX_OFDM0) ?
rx_rate - 1 : rx_rate;
+ if (rate_index >= MWIFIEX_MAX_AC_RX_RATES)
+ rate_index = MWIFIEX_MAX_AC_RX_RATES - 1;
+
return rate_index;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 066/317] mac80211/cfg80211: update bss channel on channel switch
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergey Matyukevich, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]
FullMAC STAs have no way to update bss channel after CSA channel switch
completion. As a result, user-space tools may provide inconsistent
channel info. For instance, consider the following two commands:
$ sudo iw dev wlan0 link
$ sudo iw dev wlan0 info
The latter command gets channel info from the hardware, so most probably
its output will be correct. However the former command gets channel info
from scan cache, so its output will contain outdated channel info.
In fact, current bss channel info will not be updated until the
next [re-]connect.
Note that mac80211 STAs have a workaround for this, but it requires
access to internal cfg80211 data, see ieee80211_chswitch_work:
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->csa_chandef.chan;
This patch suggests to convert mac80211 workaround into cfg80211 behavior
and to update current bss channel in cfg80211_ch_switch_notify.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 3 ---
net/wireless/nl80211.c | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 6878215672871..715ab0e6579cb 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1167,9 +1167,6 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
}
- /* XXX: shouldn't really modify cfg80211-owned data! */
- ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 156ce708b5330..0044bfb526abc 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -15667,6 +15667,11 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+ if (wdev->iftype == NL80211_IFTYPE_STATION &&
+ !WARN_ON(!wdev->current_bss))
+ wdev->current_bss->pub.channel = chandef->chan;
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
NL80211_CMD_CH_SWITCH_NOTIFY, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 041/375] brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler()
From: Sasha Levin @ 2019-05-22 19:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
In-Reply-To: <20190522192115.22666-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
If "ret_len" is negative then it could lead to a NULL dereference.
The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
then we don't allocate the "dcmd_buf" buffer. Then we pass "ret_len" to
brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
Most of the functions in that call tree check whether the buffer we pass
is NULL but there are at least a couple places which don't such as
brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd(). We memcpy() to and
from the buffer so it would result in a NULL dereference.
The fix is to change the types so that "ret_len" can't be negative. (If
we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
issue).
Fixes: 1bacb0487d0e ("brcmfmac: replace cfg80211 testmode with vendor command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index 8eff2753abade..d493021f60318 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -35,9 +35,10 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
struct brcmf_if *ifp;
const struct brcmf_vndr_dcmd_hdr *cmdhdr = data;
struct sk_buff *reply;
- int ret, payload, ret_len;
+ unsigned int payload, ret_len;
void *dcmd_buf = NULL, *wr_pointer;
u16 msglen, maxmsglen = PAGE_SIZE - 0x100;
+ int ret;
if (len < sizeof(*cmdhdr)) {
brcmf_err("vendor command too short: %d\n", len);
@@ -65,7 +66,7 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
brcmf_err("oversize return buffer %d\n", ret_len);
ret_len = BRCMF_DCMD_MAXLEN;
}
- payload = max(ret_len, len) + 1;
+ payload = max_t(unsigned int, ret_len, len) + 1;
dcmd_buf = vzalloc(payload);
if (NULL == dcmd_buf)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* Logo printing
From: David @ 2019-05-22 11:40 UTC (permalink / raw)
To: linux-wireless
Hi,
Not sure if you received my last email?
Are you interested in purchasing your LOGO promotional and marketing
products for your company?
We produce USB Drives with your Logo Printed or artwork printed to be used
for gifts or marketing.
Here is more info from our website:
We can pre-load your media files, images, presentations and files onto the
drives for you.
Some reasons to get the USB drives from us:
We make Custom Shaped USB drives in the shape of your logo, product or
anything you like.
Our USB drives are Eco-friendly
We supply USB drives to Fortune 100 companies.
We have over 150 styles and colors to choose from.
People will keep the USB drive you give them and show it to others
increasing your marketing value
Please click
to see all of our stock models and get a quote.
If you are nonprofit, have further discounts for schools and charities.
Thanks,
David
USB Drive Specialist
http://walgreens.com/mail/link.php?M=8181310&N=2777&L=65&F=T
^ permalink raw reply
* [PATCH v3] ath10k: add support for firmware crash recovery on SDIO chip
From: Wen Gong @ 2019-05-22 6:32 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
The command to simulate firmware crash:
echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash
It will send WMI_FORCE_FW_HANG_ASSERT to firmware, then it will trigger
CPU interrupt status register for SDIO chip, ath10k driver need to
configure it while enable SDIO interrupt, otherwise ath10k driver will
not get the assert error info.
After this change, it will success for simulate firmware crash.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
v3: change commit log title
v2: add MBOX_CPU_STATUS_ENABLE_ASSERT_MASK for fw assert check
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 10 ++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7131499..60521ed 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -1095,6 +1095,7 @@ struct ath10k_hw_ops {
#define MBOX_CPU_INT_STATUS_ENABLE_ADDRESS 0x00000819
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_LSB 0
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_MASK 0x000000ff
+#define MBOX_CPU_STATUS_ENABLE_ASSERT_MASK 0x00000001
#define MBOX_ERROR_STATUS_ENABLE_ADDRESS 0x0000081a
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_LSB 1
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_MASK 0x00000002
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
index fae56c6..1a3a7bf 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -850,6 +850,10 @@ static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k *ar)
out:
mutex_unlock(&irq_data->mtx);
+ if (cpu_int_status & MBOX_CPU_STATUS_ENABLE_ASSERT_MASK) {
+ ath10k_err(ar, "firmware crashed!\n");
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
return ret;
}
@@ -1495,8 +1499,10 @@ static int ath10k_sdio_hif_enable_intrs(struct ath10k *ar)
regs->int_status_en |=
FIELD_PREP(MBOX_INT_STATUS_ENABLE_MBOX_DATA_MASK, 1);
- /* Set up the CPU Interrupt status Register */
- regs->cpu_int_status_en = 0;
+ /* Set up the CPU Interrupt Status Register, enable CPU sourced interrupt #0
+ * #0 is used for report assertion from target
+ */
+ regs->cpu_int_status_en = FIELD_PREP(MBOX_CPU_STATUS_ENABLE_ASSERT_MASK, 1);
/* Set up the Error Interrupt status Register */
regs->err_int_status_en =
--
1.9.1
^ permalink raw reply related
* RE: [PATCH v2] ath10k: add support for simulate crash on SDIO chip
From: Wen Gong @ 2019-05-22 6:24 UTC (permalink / raw)
To: Claire Chang, Wen Gong
Cc: open list:NETWORKING DRIVERS (WIRELESS),
ath10k@lists.infradead.org
In-Reply-To: <CALiNf29_GwSEUJ_vdp+_1DeDyFZj0uuUY9kYh94w4P_eeDT=8g@mail.gmail.com>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Claire
> Chang
> Sent: Wednesday, May 15, 2019 10:53 AM
> To: Wen Gong <wgong@codeaurora.org>
> Cc: open list:NETWORKING DRIVERS (WIRELESS) <linux-
> wireless@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH v2] ath10k: add support for simulate crash on SDIO
> chip
>
> Tested-by: Claire Chang <tientzu@chromium.org>
>
> If this patch adds support for detecting the real firmware assert,
> maybe the title should be "add support for _crash recovery_ on SDIO
> chip"
Yes, seems this title is more appropriate.
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* [PATCH] ath10k: fix fw crash by moving chip reset after napi disabled
From: Miaoqing Pan @ 2019-05-22 2:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Miaoqing Pan
On SMP platform, when continuously running wifi up/down, the napi
poll can be scheduled during chip reset, which will call
ath10k_pci_has_fw_crashed() to check the fw status. But in the reset
period, the value from FW_INDICATOR_ADDRESS register will return
0xdeadbeef, which also be treated as fw crash. Fix the issue by
moving chip reset after napi disabled.
ath10k_pci 0000:01:00.0: firmware crashed! (guid 73b30611-5b1e-4bdd-90b4-64c81eb947b6)
ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
ath10k_pci 0000:01:00.0: failed to get memcpy hi address for firmware address 4: -16
ath10k_pci 0000:01:00.0: failed to read firmware dump area: -16
ath10k_pci 0000:01:00.0: Copy Engine register dump:
ath10k_pci 0000:01:00.0: [00]: 0x0004a000 0 0 0 0
ath10k_pci 0000:01:00.0: [01]: 0x0004a400 0 0 0 0
ath10k_pci 0000:01:00.0: [02]: 0x0004a800 0 0 0 0
ath10k_pci 0000:01:00.0: [03]: 0x0004ac00 0 0 0 0
ath10k_pci 0000:01:00.0: [04]: 0x0004b000 0 0 0 0
ath10k_pci 0000:01:00.0: [05]: 0x0004b400 0 0 0 0
ath10k_pci 0000:01:00.0: [06]: 0x0004b800 0 0 0 0
ath10k_pci 0000:01:00.0: [07]: 0x0004bc00 1 0 1 0
ath10k_pci 0000:01:00.0: [08]: 0x0004c000 0 0 0 0
ath10k_pci 0000:01:00.0: [09]: 0x0004c400 0 0 0 0
ath10k_pci 0000:01:00.0: [10]: 0x0004c800 0 0 0 0
ath10k_pci 0000:01:00.0: [11]: 0x0004cc00 0 0 0 0
Tested HW: QCA9984
Tested FW: 10.4-3.9.0.2-00035
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/pci.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 2bd6cba..80bcb2e 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2059,6 +2059,11 @@ static void ath10k_pci_hif_stop(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif stop\n");
+ ath10k_pci_irq_disable(ar);
+ ath10k_pci_irq_sync(ar);
+ napi_synchronize(&ar->napi);
+ napi_disable(&ar->napi);
+
/* Most likely the device has HTT Rx ring configured. The only way to
* prevent the device from accessing (and possible corrupting) host
* memory is to reset the chip now.
@@ -2072,10 +2077,6 @@ static void ath10k_pci_hif_stop(struct ath10k *ar)
*/
ath10k_pci_safe_chip_reset(ar);
- ath10k_pci_irq_disable(ar);
- ath10k_pci_irq_sync(ar);
- napi_synchronize(&ar->napi);
- napi_disable(&ar->napi);
ath10k_pci_flush(ar);
spin_lock_irqsave(&ar_pci->ps_lock, flags);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] ath10k: update HOST capability qmi message
From: Bjorn Andersson @ 2019-05-22 1:20 UTC (permalink / raw)
To: Govind Singh; +Cc: ath10k, linux-wireless
In-Reply-To: <20190204115555.17052-1-govinds@codeaurora.org>
On Mon 04 Feb 03:55 PST 2019, Govind Singh wrote:
> HOST capability interface data structures are updated
> in HL3.1 fw version. Update the qmi host capability
> members for compatibility across different firmware
> versions.
> Since this change breaks backward compatibility with
> HL2.0 fw, HL2.0 fw upgrade to WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1
> or later version is required.
>
Sorry for not objecting earlier, I confused this with the "msa info req
rejected: 90" error that we see on some 845 devices.
Given that the wlan firmware is signed there's no way for people in the
community to upgrade their firmware, until such version has propagated
through the official channels for the specific device.
As such this patch inhibits the ability of bringing up wifi on devices
such as the Lenovo Yoga C630.
Is there any way we can detect if we're using the "old" firmware?
Regards,
Bjorn
> Testing:
> Tested on QCS404 platform(WCN3990 HW).
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1,
> WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1
> ---
> .../net/wireless/ath/ath10k/qmi_wlfw_v01.c | 229 +++++++++++++++++-
> .../net/wireless/ath/ath10k/qmi_wlfw_v01.h | 34 ++-
> 2 files changed, 257 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
> index ba79c2e4aed6..4102f7b0b5c3 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
> @@ -1763,14 +1763,239 @@ struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[] = {
> daemon_support_valid),
> },
> {
> - .data_type = QMI_UNSIGNED_1_BYTE,
> + .data_type = QMI_UNSIGNED_4_BYTE,
> .elem_len = 1,
> - .elem_size = sizeof(u8),
> + .elem_size = sizeof(u32),
> .array_type = NO_ARRAY,
> .tlv_type = 0x10,
> .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> daemon_support),
> },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x11,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + wake_msi_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_4_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u32),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x11,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + wake_msi),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x12,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + gpios_valid),
> + },
> + {
> + .data_type = QMI_DATA_LEN,
> + .elem_len = 1,
> + .elem_size = sizeof(u32),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x12,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + gpios_len),
> + },
> + {
> + .data_type = QMI_UNSIGNED_4_BYTE,
> + .elem_len = QMI_WLFW_MAX_NUM_GPIO_V01,
> + .elem_size = sizeof(u32),
> + .array_type = VAR_LEN_ARRAY,
> + .tlv_type = 0x12,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + gpios),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x13,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + nm_modem_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x13,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + nm_modem),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x14,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x14,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x15,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_cache_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x15,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_cache_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x16,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x16,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x17,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_cache_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x17,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_cache_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x18,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_filesys_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x18,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_filesys_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x19,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_cache_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x19,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_cache_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1A,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_done_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1A,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_done),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1B,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_bucket_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_4_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u32),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1B,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_bucket),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1C,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_cfg_mode_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1C,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_cfg_mode),
> + },
> {}
> };
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
> index c5e3870b8871..ff668f5d8afd 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
> +++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
> @@ -553,12 +553,38 @@ struct wlfw_mac_addr_resp_msg_v01 {
> #define WLFW_MAC_ADDR_RESP_MSG_V01_MAX_MSG_LEN 7
> extern struct qmi_elem_info wlfw_mac_addr_resp_msg_v01_ei[];
>
> +#define QMI_WLFW_MAX_NUM_GPIO_V01 32
> struct wlfw_host_cap_req_msg_v01 {
> u8 daemon_support_valid;
> - u8 daemon_support;
> -};
> -
> -#define WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN 4
> + u32 daemon_support;
> + u8 wake_msi_valid;
> + u32 wake_msi;
> + u8 gpios_valid;
> + u32 gpios_len;
> + u32 gpios[QMI_WLFW_MAX_NUM_GPIO_V01];
> + u8 nm_modem_valid;
> + u8 nm_modem;
> + u8 bdf_support_valid;
> + u8 bdf_support;
> + u8 bdf_cache_support_valid;
> + u8 bdf_cache_support;
> + u8 m3_support_valid;
> + u8 m3_support;
> + u8 m3_cache_support_valid;
> + u8 m3_cache_support;
> + u8 cal_filesys_support_valid;
> + u8 cal_filesys_support;
> + u8 cal_cache_support_valid;
> + u8 cal_cache_support;
> + u8 cal_done_valid;
> + u8 cal_done;
> + u8 mem_bucket_valid;
> + u32 mem_bucket;
> + u8 mem_cfg_mode_valid;
> + u8 mem_cfg_mode;
> +};
> +
> +#define WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN 189
> extern struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[];
>
> struct wlfw_host_cap_resp_msg_v01 {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH] staging: wilc1000: remove redundant masking of pkt_offset
From: Adham.Abozaeid @ 2019-05-21 18:43 UTC (permalink / raw)
To: colin.king, Ajay.Kathat, gregkh, linux-wireless, devel
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190521131706.30236-1-colin.king@canonical.com>
On 5/21/19 6:17 AM, Colin King wrote:
> External E-Mail
>
>
> From: Colin Ian King <colin.king@canonical.com>
>
> The masking update of pkg_offset is redundant as the updated
> value is never read and pkg_offset is re-assigned on the next
> iteration of the loop. Clean this up by removing the redundant
> assignment.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Adham Abozaeid <adham.abozaeid@microchip.com>
Thanks,
Adham
> ---
> drivers/staging/wilc1000/wilc_wlan.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> index 95eaf8fdf4f2..dcd728557958 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -709,9 +709,6 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc, u8 *buffer, int size)
> break;
>
> if (pkt_offset & IS_MANAGMEMENT) {
> - pkt_offset &= ~(IS_MANAGMEMENT |
> - IS_MANAGMEMENT_CALLBACK |
> - IS_MGMT_STATUS_SUCCES);
> buff_ptr += HOST_HDR_OFFSET;
> wilc_wfi_mgmt_rx(wilc, buff_ptr, pkt_len);
> } else {
^ permalink raw reply
* Re: [RFC PATCH 2/2] rtl8xxxu: Add watchdog to update rate mask by signal strength
From: Daniel Drake @ 2019-05-21 18:38 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <CAB4CAwf26pdCY7FJA5H7d1aEY2xpjSto4JxARwczmVJ==41yng@mail.gmail.com>
On Fri, May 10, 2019 at 2:37 AM Chris Chiu <chiu@endlessm.com> wrote:
> I've verified that multiple virtual interface can not work simultaneously in
> STA mode. I assigned different mac address for different vifs, I can only
> bring only one interface up. If I want to bring the second vif up, it always
> complains "SIOCSIFFLAGS: Device or resource busy".
Interesting. Can you go deeper into that so that we can be more
confident of this limitation?
ieee80211_open() is the starting point.
ieee80211_check_concurrent_iface() is one candidate to generate -EBUSY
but from inspection, I don't think that's happening in this case,
perhaps you can keep following through in order to figure out which
part of the code is not allowing the 2nd STA interface to come up.
Daniel
^ permalink raw reply
* Re: [PATCH v3 0/2] Add support for new channels on 60GHz band
From: Kalle Valo @ 2019-05-21 15:15 UTC (permalink / raw)
To: Alexei Avshalom Lazar; +Cc: Johannes Berg, linux-wireless, wil6210
In-Reply-To: <1558364020-11064-1-git-send-email-ailizaro@codeaurora.org>
Alexei Avshalom Lazar <ailizaro@codeaurora.org> writes:
> The following set of patches add support for new channels on
> 60GHz band and EDMG channels:
> -Nl80211 support for EDMG channels
> -Wil6210 support for EDMG channels
>
> Alexei Avshalom Lazar (2):
> nl80211: Add support for EDMG channels
> wil6210: Add EDMG channel support
Please always add a changelog to help the reviewers:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
--
Kalle Valo
^ permalink raw reply
* [PATCH 1/2] mac80211: add ieee80211_get_he_iftype_cap() helper
From: John Crispin @ 2019-05-21 15:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath11k, John Crispin, Shashidhar Lakkavalli
This function is similar to ieee80211_get_he_sta_cap() but allows passing
the iftype. Also make ieee80211_get_he_sta_cap() use the new helper
rather than duplicating the code.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
include/net/cfg80211.h | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 3f67f01b5f7a..379202ff3d14 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -395,16 +395,18 @@ ieee80211_get_sband_iftype_data(const struct ieee80211_supported_band *sband,
}
/**
- * ieee80211_get_he_sta_cap - return HE capabilities for an sband's STA
- * @sband: the sband to search for the STA on
+ * ieee80211_get_he_iftype_cap - return HE capabilities for an sband's iftype
+ * @sband: the sband to search for the iftype on
+ * @iftype: enum nl80211_iftype
*
* Return: pointer to the struct ieee80211_sta_he_cap, or NULL is none found
*/
static inline const struct ieee80211_sta_he_cap *
-ieee80211_get_he_sta_cap(const struct ieee80211_supported_band *sband)
+ieee80211_get_he_iftype_cap(const struct ieee80211_supported_band *sband,
+ u8 iftype)
{
const struct ieee80211_sband_iftype_data *data =
- ieee80211_get_sband_iftype_data(sband, NL80211_IFTYPE_STATION);
+ ieee80211_get_sband_iftype_data(sband, iftype);
if (data && data->he_cap.has_he)
return &data->he_cap;
@@ -412,6 +414,18 @@ ieee80211_get_he_sta_cap(const struct ieee80211_supported_band *sband)
return NULL;
}
+/**
+ * ieee80211_get_he_sta_cap - return HE capabilities for an sband's STA
+ * @sband: the sband to search for the STA on
+ *
+ * Return: pointer to the struct ieee80211_sta_he_cap, or NULL is none found
+ */
+static inline const struct ieee80211_sta_he_cap *
+ieee80211_get_he_sta_cap(const struct ieee80211_supported_band *sband)
+{
+ return ieee80211_get_he_iftype_cap(sband, NL80211_IFTYPE_STATION);
+}
+
/**
* wiphy_read_of_freq_limits - read frequency limits from device tree
*
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox