summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2020-11-18ath9k_htc: Use appropriate rs_datalen typeMasashi Honma1-1/+1
commit 5024f21c159f8c1668f581fff37140741c0b1ba9 upstream. kernel test robot says: drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:987:20: sparse: warning: incorrect type in assignment (different base types) drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:987:20: sparse: expected restricted __be16 [usertype] rs_datalen drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:987:20: sparse: got unsigned short [usertype] drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:988:13: sparse: warning: restricted __be16 degrades to integer drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:1001:13: sparse: warning: restricted __be16 degrades to integer Indeed rs_datalen has host byte order, so modify it's own type. Reported-by: kernel test robot <lkp@intel.com> Fixes: cd486e627e67 ("ath9k_htc: Discard undersized packets") Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200808233258.4596-1-masashi.honma@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10ath10k: fix VHT NSS calculation when STBC is enabledSathishkumar Muruganandam1-1/+7
[ Upstream commit 99f41b8e43b8b4b31262adb8ac3e69088fff1289 ] When STBC is enabled, NSTS_SU value need to be accounted for VHT NSS calculation for SU case. Without this fix, 1SS + STBC enabled case was reported wrongly as 2SS in radiotap header on monitor mode capture. Tested-on: QCA9984 10.4-3.10-00047 Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1597392971-3897-1-git-send-email-murugana@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10p54: avoid accessing the data mapped to streaming DMAJia-Ju Bai1-1/+3
commit 478762855b5ae9f68fa6ead1edf7abada70fcd5f upstream. In p54p_tx(), skb->data is mapped to streaming DMA on line 337: mapping = pci_map_single(..., skb->data, ...); Then skb->data is accessed on line 349: desc->device_addr = ((struct p54_hdr *)skb->data)->req_id; This access may cause data inconsistency between CPU cache and hardware. To fix this problem, ((struct p54_hdr *)skb->data)->req_id is stored in a local variable before DMA mapping, and then the driver accesses this local variable instead of skb->data. Cc: <stable@vger.kernel.org> Signed-off-by: Jia-Ju Bai <baijiaju@tsinghua.edu.cn> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802132949.26788-1-baijiaju@tsinghua.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n()Zekun Shen1-0/+8
[ Upstream commit bad60b8d1a7194df38fd7fe4b22f3f4dcf775099 ] The idx in __ath10k_htt_rx_ring_fill_n function lives in consistent dma region writable by the device. Malfunctional or malicious device could manipulate such idx to have a OOB write. Either by htt->rx_ring.netbufs_ring[idx] = skb; or by ath10k_htt_set_paddrs_ring(htt, paddr, idx); The idx can also be negative as it's signed, giving a large memory space to write to. It's possibly exploitable by corruptting a legit pointer with a skb pointer. And then fill skb with payload as rougue object. Part of the log here. Sometimes it appears as UAF when writing to a freed memory by chance. [ 15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0 [ 15.595483] #PF: supervisor write access in kernel mode [ 15.596250] #PF: error_code(0x0002) - not-present page [ 15.597013] PGD 0 P4D 0 [ 15.597395] Oops: 0002 [#1] SMP KASAN PTI [ 15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69 [ 15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] [ 15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200623221105.3486-1-bruceshenzk@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcm80211: fix possible memleak in brcmf_proto_msgbuf_attachWang Yufen1-0/+2
[ Upstream commit 6c151410d5b57e6bb0d91a735ac511459539a7bf ] When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL, we should destroy the workqueue. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1595237765-66238-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtl8xxxu: prevent potential memory leakChris Chiu1-1/+9
[ Upstream commit 86279456a4d47782398d3cb8193f78f672e36cac ] Free the skb if usb_submit_urb fails on rx_urb. And free the urb no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200906040424.22022-1-chiu@endlessm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcmsmac: fix memory leak in wlc_phy_attach_lcnphyKeita Suzuki1-1/+3
[ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ] When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy, the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be freed in the caller function. Fix this by calling wlc_phy_detach_lcnphy in the error handler of wlc_phy_txpwr_srom_read_lcnphy before returning. Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath9k: hif_usb: fix race condition between usb_get_urb() and ↵Brooke Basile1-0/+19
usb_kill_anchored_urbs() [ Upstream commit 03fb92a432ea5abe5909bca1455b7e44a9380480 ] Calls to usb_kill_anchored_urbs() after usb_kill_urb() on multiprocessor systems create a race condition in which usb_kill_anchored_urbs() deallocates the URB before the completer callback is called in usb_kill_urb(), resulting in a use-after-free. To fix this, add proper lock protection to usb_kill_urb() calls that can possibly run concurrently with usb_kill_anchored_urbs(). Reported-by: syzbot+89bd486af9427a9fc605@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf Signed-off-by: Brooke Basile <brookebasile@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200911071427.32354-1-brookebasile@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: fix double freeTom Rix1-0/+2
[ Upstream commit 53708f4fd9cfe389beab5c8daa763bcd0e0b4aef ] clang static analysis reports this problem: sdio.c:2403:3: warning: Attempt to free released memory kfree(card->mpa_rx.buf); ^~~~~~~~~~~~~~~~~~~~~~~ When mwifiex_init_sdio() fails in its first call to mwifiex_alloc_sdio_mpa_buffer, it falls back to calling it again. If the second alloc of mpa_tx.buf fails, the error handler will try to free the old, previously freed mpa_rx.buf. Reviewing the code, it looks like a second double free would happen with mwifiex_cleanup_sdio(). So set both pointers to NULL when they are freed. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201004131931.29782-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29iwlwifi: mvm: split a print to avoid a WARNING in ROCEmmanuel Grumbach1-3/+6
[ Upstream commit 903b3f9badf1d54f77b468b96706dab679b45b14 ] A print in the remain on channel code was too long and caused a WARNING, split it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: dc28e12f2125 ("iwlwifi: mvm: ROC: Extend the ROC max delay duration & limit ROC duration") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930102759.58d57c0bdc68.Ib06008665e7bf1199c360aa92691d9c74fb84990@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath6kl: wmi: prevent a shift wrapping bug in ath6kl_wmi_delete_pstream_cmd()Dan Carpenter1-0/+5
[ Upstream commit 6a950755cec1a90ddaaff3e4acb5333617441c32 ] The "tsid" is a user controlled u8 which comes from debugfs. Values more than 15 are invalid because "active_tsids" is a 16 bit variable. If the value of "tsid" is more than 31 then that leads to a shift wrapping bug. Fixes: 8fffd9e5ec9e ("ath6kl: Implement support for QOS-enable and QOS-disable from userspace") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200918142732.GA909725@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: Do not use GFP_KERNEL in atomic contextChristophe JAILLET1-1/+1
[ Upstream commit d2ab7f00f4321370a8ee14e5630d4349fdacc42e ] A possible call chain is as follow: mwifiex_sdio_interrupt (sdio.c) --> mwifiex_main_process (main.c) --> mwifiex_process_cmdresp (cmdevt.c) --> mwifiex_process_sta_cmdresp (sta_cmdresp.c) --> mwifiex_ret_802_11_scan (scan.c) --> mwifiex_parse_single_response_buf (scan.c) 'mwifiex_sdio_interrupt()' is an interrupt function. Also note that 'mwifiex_ret_802_11_scan()' already uses GFP_ATOMIC. So use GFP_ATOMIC instead of GFP_KERNEL when memory is allocated in 'mwifiex_parse_single_response_buf()'. Fixes: 7c6fa2a843c5 ("mwifiex: use cfg80211 dynamic scan table and cfg80211_get_bss API") or Fixes: 601216e12c65e ("mwifiex: process RX packets in SDIO IRQ thread directly") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200809092906.744621-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29wcn36xx: Fix reported 802.11n rx_highest rate wcn3660/wcn3680Bryan O'Donoghue1-1/+1
[ Upstream commit 3b9fb6791e7113679b1eb472e6ce1659e80f5797 ] Qualcomm's document "80-WL007-1 Rev. J" states that the highest rx rate for the WCN3660 and WCN3680 on MCS 7 is 150 Mbps not the 72 Mbps stated here. This patch fixes the data-rate declared in the 5GHz table. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802004824.1307124-1-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath9k: Fix potential out of bounds in ath9k_htc_txcompletion_cb()Dan Carpenter1-0/+2
[ Upstream commit 2705cd7558e718a7240c64eb0afb2edad5f8c190 ] The value of "htc_hdr->endpoint_id" comes from skb->data so Smatch marks it as untrusted so we have to check it before using it as an array offset. This is similar to a bug that syzkaller found in commit e4ff08a4d727 ("ath9k: Fix use-after-free Write in ath9k_htc_rx_msg") so it is probably a real issue. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200813141253.GA457408@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath6kl: prevent potential array overflow in ath6kl_add_new_sta()Dan Carpenter1-0/+3
[ Upstream commit 54f9ab7b870934b70e5a21786d951fbcf663970f ] The value for "aid" comes from skb->data so Smatch marks it as untrusted. If it's invalid then it can result in an out of bounds array access in ath6kl_add_new_sta(). Fixes: 572e27c00c9d ("ath6kl: Fix AP mode connect event parsing and TIM updates") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200813141315.GB457408@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath10k: provide survey info as accumulated dataVenkateswara Naralasetty1-1/+1
[ Upstream commit 720e5c03e5cb26d33d97f55192b791bb48478aa5 ] It is expected that the returned counters by .get_survey are monotonic increasing. But the data from ath10k gets reset to zero regularly. Channel active/busy time are then showing incorrect values (less than previous or sometimes zero) for the currently active channel during successive survey dump commands. example: $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 54995 ms channel busy time: 432 ms channel receive time: 0 ms channel transmit time: 59 ms ... $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 32592 ms channel busy time: 254 ms channel receive time: 0 ms channel transmit time: 0 ms ... The correct way to handle this is to use the non-clearing WMI_BSS_SURVEY_REQ_TYPE_READ wmi_bss_survey_req_type. The firmware will then accumulate the survey data and handle wrap arounds. Tested-on: QCA9984 hw1.0 10.4-3.5.3-00057 Tested-on: QCA988X hw2.0 10.2.4-1.0-00047 Tested-on: QCA9888 hw2.0 10.4-3.9.0.2-00024 Tested-on: QCA4019 hw1.0 10.4-3.6-00140 Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information") Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org> Tested-by: Markus Theil <markus.theil@tu-ilmenau.de> Tested-by: John Deere <24601deerej@gmail.com> [sven@narfation.org: adjust commit message] Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1592232686-28712-1-git-send-email-kvalo@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01mwifiex: Increase AES key storage size to 256 bitsMaximilian Luz2-3/+3
[ Upstream commit 4afc850e2e9e781976fb2c7852ce7bac374af938 ] Following commit e18696786548 ("mwifiex: Prevent memory corruption handling keys") the mwifiex driver fails to authenticate with certain networks, specifically networks with 256 bit keys, and repeatedly asks for the password. The kernel log repeats the following lines (id and bssid redacted): mwifiex_pcie 0000:01:00.0: info: trying to associate to '<id>' bssid <bssid> mwifiex_pcie 0000:01:00.0: info: associated to bssid <bssid> successfully mwifiex_pcie 0000:01:00.0: crypto keys added mwifiex_pcie 0000:01:00.0: info: successfully disconnected from <bssid>: reason code 3 Tracking down this problem lead to the overflow check introduced by the aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This check fails on networks with 256 bit keys due to the current storage size for AES keys in struct mwifiex_aes_param being only 128 bit. To fix this issue, increase the storage size for AES keys to 256 bit. Fixes: e18696786548 ("mwifiex: Prevent memory corruption handling keys") Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reported-by: Kaloyan Nikolov <konik98@gmail.com> Tested-by: Kaloyan Nikolov <konik98@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200825153829.38043-1-luzmaximilian@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01ar5523: Add USB ID of SMCWUSBT-G2 wireless adapterMert Dirik1-0/+2
[ Upstream commit 5b362498a79631f283578b64bf6f4d15ed4cc19a ] Add the required USB ID for running SMCWUSBT-G2 wireless adapter (SMC "EZ Connect g"). This device uses ar5523 chipset and requires firmware to be loaded. Even though pid of the device is 4507, this patch adds it as 4506 so that AR5523_DEVICE_UG macro can set the AR5523_FLAG_PRE_FIRMWARE flag for pid 4507. Signed-off-by: Mert Dirik <mertdirik@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-03Revert "ath10k: fix DMA related firmware crashes on multiple devices"Zhi Chen1-1/+1
[ Upstream commit a1769bb68a850508a492e3674ab1e5e479b11254 ] This reverts commit 76d164f582150fd0259ec0fcbc485470bcd8033e. PCIe hung issue was observed on multiple platforms. The issue was reproduced when DUT was configured as AP and associated with 50+ STAs. For QCA9984/QCA9888, the DMA_BURST_SIZE register controls the AXI burst size of the RD/WR access to the HOST MEM. 0 - No split , RAW read/write transfer size from MAC is put out on bus as burst length 1 - Split at 256 byte boundary 2,3 - Reserved With PCIe protocol analyzer, we can see DMA Read crossing 4KB boundary when issue happened. It broke PCIe spec and caused PCIe stuck. So revert the default value from 0 to 1. Tested: IPQ8064 + QCA9984 with firmware 10.4-3.10-00047 QCS404 + QCA9984 with firmware 10.4-3.9.0.2--00044 Synaptics AS370 + QCA9888 with firmware 10.4-3.9.0.2--00040 Signed-off-by: Zhi Chen <zhichen@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-03rtlwifi: rtl8192cu: Prevent leaking urbReto Schneider1-1/+4
[ Upstream commit 03128643eb5453a798db5770952c73dc64fcaf00 ] If usb_submit_urb fails the allocated urb should be unanchored and released. Signed-off-by: Reto Schneider <code@reto-schneider.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200622132113.14508-3-code@reto-schneider.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21wl1251: fix always return 0 errorWang Hai1-1/+1
[ Upstream commit 20e6421344b5bc2f97b8e2db47b6994368417904 ] wl1251_event_ps_report() should not always return 0 because wl1251_ps_set_mode() may fail. Change it to return 'ret'. Fixes: f7ad1eed4d4b ("wl1251: retry power save entry") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200730073939.33704-1-wanghai38@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21mwifiex: Prevent memory corruption handling keysDan Carpenter1-7/+15
[ Upstream commit e18696786548244914f36ec3c46ac99c53df99c3 ] The length of the key comes from the network and it's a 16 bit number. It needs to be capped to prevent a buffer overflow. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200708115857.GA13729@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21iwlegacy: Check the return value of pcie_capability_read_*()Bolarinwa Olayemi Saheed1-2/+2
[ Upstream commit 9018fd7f2a73e9b290f48a56b421558fa31e8b75 ] On failure pcie_capability_read_dword() sets it's last parameter, val to 0. However, with Patch 14/14, it is possible that val is set to ~0 on failure. This would introduce a bug because (x & x) == (~0 & x). This bug can be avoided without changing the function's behaviour if the return value of pcie_capability_read_dword is checked to confirm success. Check the return value of pcie_capability_read_dword() to ensure success. Suggested-by: Bjorn Helgaas <bjorn@helgaas.com> Signed-off-by: Bolarinwa Olayemi Saheed <refactormyself@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200713175529.29715-3-refactormyself@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21brcmfmac: To fix Bss Info flag definition BugPrasanna Kerekoppa1-1/+1
[ Upstream commit fa3266541b13f390eb35bdbc38ff4a03368be004 ] Bss info flag definition need to be fixed from 0x2 to 0x4 This flag is for rssi info received on channel. All Firmware branches defined as 0x4 and this is bug in brcmfmac. Signed-off-by: Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200604071835.3842-6-wright.feng@cypress.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21ath9k: release allocated buffer if timed outNavid Emamdoost1-0/+1
[ Upstream commit 728c1e2a05e4b5fc52fab3421dce772a806612a2 ] In ath9k_wmi_cmd, the allocated network buffer needs to be released if timeout happens. Otherwise memory will be leaked. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21ath9k_htc: release allocated buffer if timed outNavid Emamdoost1-0/+3
[ Upstream commit 853acf7caf10b828102d92d05b5c101666a6142b ] In htc_config_pipe_credits, htc_setup_complete, and htc_connect_service if time out happens, the allocated buffer needs to be released. Otherwise there will be memory leak. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-31ath9k: Fix regression with Atheros 9271Mark O'Donovan1-1/+3
commit 92f53e2fda8bb9a559ad61d57bfb397ce67ed0ab upstream. This fix allows ath9k_htc modules to connect to WLAN once again. Fixes: 2bbcaaee1fcb ("ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb") Link: https://bugzilla.kernel.org/show_bug.cgi?id=208251 Signed-off-by: Mark O'Donovan <shiftee@posteo.net> Reported-by: Roman Mamedov <rm@romanrm.net> Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200711043324.8079-1-shiftee@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-31ath9k: Fix general protection fault in ath9k_hif_usb_rx_cbQiujun Huang2-11/+42
commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. In ath9k_hif_usb_rx_cb interface number is assumed to be 0. usb_ifnum_to_if(urb->dev, 0) But it isn't always true. The case reported by syzbot: https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com usb 2-1: new high-speed USB device number 2 using dummy_hcd usb 2-1: config 1 has an invalid interface number: 2 but max is 0 usb 2-1: config 1 has no interface number 0 usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 general protection fault, probably for non-canonical address 0xdffffc0000000015: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0 Call Trace __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 __do_softirq+0x21e/0x950 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:546 [inline] smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com Cc: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-22Revert "ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb"Greg Kroah-Hartman2-42/+11
This reverts commit 5317abc46279d900c7e63cc122682d819da658bd which is commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. It is being reverted upstream, just hasn't made it there yet and is causing lots of problems. Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Qiujun Huang <hqjagain@gmail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20b43_legacy: Fix connection problem with WPA3Larry Finger1-0/+1
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream. Since the driver was first introduced into the kernel, it has only handled the ciphers associated with WEP, WPA, and WPA2. It fails with WPA3 even though mac80211 can handle those additional ciphers in software, b43legacy did not report that it could handle them. By setting MFP_CAPABLE using ieee80211_set_hw(), the problem is fixed. With this change, b43legacy will handle the ciphers it knows in hardware, and let mac80211 handle the others in software. It is not necessary to use the module parameter NOHWCRYPT to turn hardware encryption off. Although this change essentially eliminates that module parameter, I am choosing to keep it for cases where the hardware is broken, and software encryption is required for all ciphers. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200526155909.5807-3-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20b43: Fix connection problem with WPA3Larry Finger1-1/+1
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream. Since the driver was first introduced into the kernel, it has only handled the ciphers associated with WEP, WPA, and WPA2. It fails with WPA3 even though mac80211 can handle those additional ciphers in software, b43 did not report that it could handle them. By setting MFP_CAPABLE using ieee80211_set_hw(), the problem is fixed. With this change, b43 will handle the ciphers it knows in hardware, and let mac80211 handle the others in software. It is not necessary to use the module parameter NOHWCRYPT to turn hardware encryption off. Although this change essentially eliminates that module parameter, I am choosing to keep it for cases where the hardware is broken, and software encryption is required for all ciphers. Reported-and-tested-by: Rui Salvaterra <rsalvaterra@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200526155909.5807-2-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20b43legacy: Fix case where channel status is corruptedLarry Finger1-0/+1
commit ec4d3e3a054578de34cd0b587ab8a1ac36f629d9 upstream. This patch fixes commit 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices") In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in b43legacy is reported. Upon testing, thus problem exists on PPC and X86 platforms, is present in the oldest kernel tested (3.2), and has been present in the driver since it was first added to the kernel. The problem is a corrupted channel status received from the device. Both the internal card in a PowerBook G4 and the PCMCIA version (Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2 (revision 4 of the 802.11 core) of the chip has been tested. No other devices using b43legacy are available for testing. Various sources of the problem were considered. Buffer overrun and other sources of corruption within the driver were rejected because the faulty channel status is always the same, not a random value. It was concluded that the faulty data is coming from the device, probably due to a firmware bug. As that source is not available, the driver must take appropriate action to recover. At present, the driver reports the error, and them continues to process the bad packet. This is believed that to be a mistake, and the correct action is to drop the correpted packet. Fixes: 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices") Cc: Stable <stable@vger.kernel.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-and-tested by: F. Erhard <erhard_f@mailbox.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20carl9170: remove P2P_GO supportChristian Lamparter2-20/+5
commit b14fba7ebd04082f7767a11daea7f12f3593de22 upstream. This patch follows up on a bug-report by Frank Schäfer that discovered P2P GO wasn't working with wpa_supplicant. This patch removes part of the broken P2P GO support but keeps the vif switchover code in place. Cc: <stable@vger.kernel.org> Link: <https://lkml.kernel.org/r/3a9d86b6-744f-e670-8792-9167257edef8@googlemail.com> Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200425092811.9494-1-chunkeey@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20mwifiex: Fix memory corruption in dump_stationPali Rohár1-8/+6
[ Upstream commit 3aa42bae9c4d1641aeb36f1a8585cd1d506cf471 ] The mwifiex_cfg80211_dump_station() uses static variable for iterating over a linked list of all associated stations (when the driver is in UAP role). This has a race condition if .dump_station is called in parallel for multiple interfaces. This corruption can be triggered by registering multiple SSIDs and calling, in parallel for multiple interfaces iw dev <iface> station dump [16750.719775] Unable to handle kernel paging request at virtual address dead000000000110 ... [16750.899173] Call trace: [16750.901696] mwifiex_cfg80211_dump_station+0x94/0x100 [mwifiex] [16750.907824] nl80211_dump_station+0xbc/0x278 [cfg80211] [16750.913160] netlink_dump+0xe8/0x320 [16750.916827] netlink_recvmsg+0x1b4/0x338 [16750.920861] ____sys_recvmsg+0x7c/0x2b0 [16750.924801] ___sys_recvmsg+0x70/0x98 [16750.928564] __sys_recvmsg+0x58/0xa0 [16750.932238] __arm64_sys_recvmsg+0x28/0x30 [16750.936453] el0_svc_common.constprop.3+0x90/0x158 [16750.941378] do_el0_svc+0x74/0x90 [16750.944784] el0_sync_handler+0x12c/0x1a8 [16750.948903] el0_sync+0x114/0x140 [16750.952312] Code: f9400003 f907f423 eb02007f 54fffd60 (b9401060) [16750.958583] ---[ end trace c8ad181c2f4b8576 ]--- This patch drops the use of the static iterator, and instead every time the function is called iterates to the idx-th position of the linked-list. It would be better to convert the code not to use linked list for associated stations storage (since the chip has a limited number of associated stations anyway - it could just be an array). Such a change may be proposed in the future. In the meantime this patch can backported into stable kernels in this simple form. Fixes: 8baca1a34d4c ("mwifiex: dump station support in uap mode") Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200515075924.13841-1-pali@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-20rtlwifi: Fix a double free in _rtl_usb_tx_urb_setup()Dan Carpenter1-6/+2
[ Upstream commit beb12813bc75d4a23de43b85ad1c7cb28d27631e ] Seven years ago we tried to fix a leak but actually introduced a double free instead. It was an understandable mistake because the code was a bit confusing and the free was done in the wrong place. The "skb" pointer is freed in both _rtl_usb_tx_urb_setup() and _rtl_usb_transmit(). The free belongs _rtl_usb_transmit() instead of _rtl_usb_tx_urb_setup() and I've cleaned the code up a bit to hopefully make it more clear. Fixes: 36ef0b473fbf ("rtlwifi: usb: add missing freeing of skbuff") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200513093951.GD347693@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-20ath9k: Fix general protection fault in ath9k_hif_usb_rx_cbQiujun Huang2-11/+42
commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. In ath9k_hif_usb_rx_cb interface number is assumed to be 0. usb_ifnum_to_if(urb->dev, 0) But it isn't always true. The case reported by syzbot: https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com usb 2-1: new high-speed USB device number 2 using dummy_hcd usb 2-1: config 1 has an invalid interface number: 2 but max is 0 usb 2-1: config 1 has no interface number 0 usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 general protection fault, probably for non-canonical address 0xdffffc0000000015: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0 Call Trace __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 __do_softirq+0x21e/0x950 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:546 [inline] smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cbQiujun Huang1-0/+5
commit 19d6c375d671ce9949a864fb9a03e19f5487b4d3 upstream. Add barrier to accessing the stack array skb_pool. The case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000003d7c1505a2168418@google.com BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline] BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_cb+0xdf6/0xf70 drivers/net/wireless/ath/ath9k/hif_usb.c:666 Write of size 8 at addr ffff8881db309a28 by task swapper/1/0 Call Trace: ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline] ath9k_hif_usb_rx_cb+0xdf6/0xf70 drivers/net/wireless/ath/ath9k/hif_usb.c:666 __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1648 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1713 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+d403396d4df67ad0bd5f@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200404041838.10426-5-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20ath9k: Fix use-after-free Write in ath9k_htc_rx_msgQiujun Huang1-0/+3
commit e4ff08a4d727146bb6717a39a8d399d834654345 upstream. Write out of slab bounds. We should check epid. The case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000006ac55b05a1c05d72@google.com BUG: KASAN: use-after-free in htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline] BUG: KASAN: use-after-free in ath9k_htc_rx_msg+0xa25/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:443 Write of size 2 at addr ffff8881cea291f0 by task swapper/1/0 Call Trace: htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline] ath9k_htc_rx_msg+0xa25/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:443 ath9k_hif_usb_reg_in_cb+0x1ba/0x630 drivers/net/wireless/ath/ath9k/hif_usb.c:718 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+b1c61e5f11be5782f192@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200404041838.10426-4-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rxQiujun Huang5-7/+17
commit abeaa85054ff8cfe8b99aafc5c70ea067e5d0908 upstream. Free wmi later after cmd urb has been killed, as urb cb will access wmi. the case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000000002fc05a1d61a68@google.com BUG: KASAN: use-after-free in ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215 Read of size 1 at addr ffff8881cef1417c by task swapper/1/0 Call Trace: <IRQ> ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215 ath9k_htc_rx_msg+0x2da/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:459 ath9k_hif_usb_reg_in_cb+0x1ba/0x630 drivers/net/wireless/ath/ath9k/hif_usb.c:718 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+5d338854440137ea0fef@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200404041838.10426-3-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-20ath9k_htc: Silence undersized packet warningsMasashi Honma1-3/+3
[ Upstream commit 450edd2805982d14ed79733a82927d2857b27cac ] Some devices like TP-Link TL-WN722N produces this kind of messages frequently. kernel: ath: phy0: Short RX data len, dropping (dlen: 4) This warning is useful for developers to recognize that the device (Wi-Fi dongle or USB hub etc) is noisy but not for general users. So this patch make this warning to debug message. Reported-By: Denis <pro.denis@protonmail.com> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207539 Fixes: cd486e627e67 ("ath9k_htc: Discard undersized packets") Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504214443.4485-1-masashi.honma@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-11airo: Fix read overflows sending packetsDan Carpenter1-0/+12
commit 11e7a91994c29da96d847f676be023da6a2c1359 upstream. The problem is that we always copy a minimum of ETH_ZLEN (60) bytes from skb->data even when skb->len is less than ETH_ZLEN so it leads to a read overflow. The fix is to pad skb->data to at least ETH_ZLEN bytes. Cc: <stable@vger.kernel.org> Reported-by: Hu Jiahui <kirin.say@gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200527184830.GA1164846@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-11p54usb: add AirVasT USB stick device-idGiuseppe Marco Randazzo1-0/+1
commit 63e49a9fdac1b4e97ac26cb3fe953f210d83bc53 upstream. This patch adds the AirVasT USB wireless devices 124a:4026 to the list of supported devices. It's using the ISL3886 usb firmware. Without this modification, the wiki adapter is not recognized. Cc: <stable@vger.kernel.org> Signed-off-by: Giuseppe Marco Randazzo <gmrandazzo@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> [formatted, reworded] Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200405220659.45621-1-chunkeey@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24wil6210: fix length check in __wmi_sendLior David2-2/+22
[ Upstream commit 26a6d5274865532502c682ff378ac8ebe2886238 ] The current length check: sizeof(cmd) + len > r->entry_size will allow very large values of len (> U16_MAX - sizeof(cmd)) and can cause a buffer overflow. Fix the check to cover this case. In addition, ensure the mailbox entry_size is not too small, since this can also bypass the above check. Signed-off-by: Lior David <qca_liord@qca.qualcomm.com> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24wil6210: rate limit wil_rx_refill errorDedy Lansky1-2/+2
[ Upstream commit 3d6b72729cc2933906de8d2c602ae05e920b2122 ] wil_err inside wil_rx_refill can flood the log buffer. Replace it with wil_err_ratelimited. Signed-off-by: Dedy Lansky <dlansky@codeaurora.org> Signed-off-by: Maya Erez <merez@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24wil6210: fix temperature debugfsDedy Lansky1-3/+4
[ Upstream commit 6d9eb7ebae3d7e951bc0999235ae7028eb4cae4f ] For negative temperatures, "temp" debugfs is showing wrong values. Use signed types so proper calculations is done for sub zero temperatures. Signed-off-by: Dedy Lansky <dlansky@codeaurora.org> Signed-off-by: Maya Erez <merez@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24wil6210: increase firmware ready timeoutHamad Kadmany1-1/+1
[ Upstream commit 6ccae584014ef7074359eb4151086beef66ecfa9 ] Firmware ready event may take longer than current timeout in some scenarios, for example with multiple RFs connected where each requires an initial calibration. Increase the timeout to support these scenarios. Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org> Signed-off-by: Maya Erez <merez@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24mac80211_hwsim: Use kstrndup() in place of kasprintf()Tuomas Tynkkynen1-6/+6
commit 7ea862048317aa76d0f22334202779a25530980c upstream. syzbot reports a warning: precision 33020 too large WARNING: CPU: 0 PID: 9618 at lib/vsprintf.c:2471 set_precision+0x150/0x180 lib/vsprintf.c:2471 vsnprintf+0xa7b/0x19a0 lib/vsprintf.c:2547 kvasprintf+0xb2/0x170 lib/kasprintf.c:22 kasprintf+0xbb/0xf0 lib/kasprintf.c:59 hwsim_del_radio_nl+0x63a/0x7e0 drivers/net/wireless/mac80211_hwsim.c:3625 genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline] ... entry_SYSCALL_64_after_hwframe+0x49/0xbe Thus it seems that kasprintf() with "%.*s" format can not be used for duplicating a string with arbitrary length. Replace it with kstrndup(). Note that later this string is limited to NL80211_WIPHY_NAME_MAXLEN == 64, but the code is simpler this way. Reported-by: syzbot+6693adf1698864d21734@syzkaller.appspotmail.com Reported-by: syzbot+a4aee3f42d7584d76761@syzkaller.appspotmail.com Cc: stable@kernel.org Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Link: https://lore.kernel.org/r/20200410123257.14559-1-tuomas.tynkkynen@iki.fi [johannes: add note about length limit] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24ath9k: Handle txpower changes even when TPC is disabledRemi Pommarel1-0/+3
commit 968ae2caad0782db5dbbabb560d3cdefd2945d38 upstream. When TPC is disabled IEEE80211_CONF_CHANGE_POWER event can be handled to reconfigure HW's maximum txpower. This fixes 0dBm txpower setting when user attaches to an interface for the first time with the following scenario: ieee80211_do_open() ath9k_add_interface() ath9k_set_txpower() /* Set TX power with not yet initialized sc->hw->conf.power_level */ ieee80211_hw_config() /* Iniatilize sc->hw->conf.power_level and raise IEEE80211_CONF_CHANGE_POWER */ ath9k_config() /* IEEE80211_CONF_CHANGE_POWER is ignored */ This issue can be reproduced with the following: $ modprobe -r ath9k $ modprobe ath9k $ wpa_supplicant -i wlan0 -c /tmp/wpa.conf & $ iw dev /* Here TX power is either 0 or 3 depending on RF chain */ $ killall wpa_supplicant $ iw dev /* TX power goes back to calibrated value and subsequent calls will be fine */ Fixes: 283dd11994cde ("ath9k: add per-vif TX power capability") Cc: stable@vger.kernel.org Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-20mwifiex: Fix heap overflow in mmwifiex_process_tdls_action_frame()qize wang1-6/+64
commit 1e58252e334dc3f3756f424a157d1b7484464c40 upstream. mwifiex_process_tdls_action_frame() without checking the incoming tdls infomation element's vality before use it, this may cause multi heap buffer overflows. Fix them by putting vality check before use it. IE is TLV struct, but ht_cap and ht_oper aren’t TLV struct. the origin marvell driver code is wrong: memcpy(&sta_ptr->tdls_cap.ht_oper, pos,.... memcpy((u8 *)&sta_ptr->tdls_cap.ht_capb, pos,... Fix the bug by changing pos(the address of IE) to pos+2 ( the address of IE value ). Signed-off-by: qize wang <wangqize888888888@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-11iwlwifi: pcie: fix rb_allocator workqueue allocationJohannes Berg1-1/+5
commit 8188a18ee2e48c9a7461139838048363bfce3fef upstream We don't handle failures in the rb_allocator workqueue allocation correctly. To fix that, move the code earlier so the cleanup is easier and we don't have to undo all the interrupt allocations in this case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> [Ajay: Rewrote this patch for v4.9.y, as 4.9.y codebase is different from mainline] Signed-off-by: Ajay Kaher <akaher@vmware.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-24 05:58:53 +0300