summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-12-01wifi: mac80211: fix and simplify unencrypted drop check for meshFelix Fietkau1-28/+10
ieee80211_drop_unencrypted is called from ieee80211_rx_h_mesh_fwding and ieee80211_frame_allowed. Since ieee80211_rx_h_mesh_fwding can forward packets for other mesh nodes and is called earlier, it needs to check the decryptions status and if the packet is using the control protocol on its own, instead of deferring to the later call from ieee80211_frame_allowed. Because of that, ieee80211_drop_unencrypted has a mesh specific check that skips over the mesh header in order to check the payload protocol. This code is invalid when called from ieee80211_frame_allowed, since that happens after the 802.11->802.3 conversion. Fix this by moving the mesh specific check directly into ieee80211_rx_h_mesh_fwding. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20221201135730.19723-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: mac80211: add support for restricting netdev features per vifFelix Fietkau4-103/+202
This can be used to selectively disable feature flags for checksum offload, scatter/gather or GSO by changing vif->netdev_features. Removing features from vif->netdev_features does not affect the netdev features themselves, but instead fixes up skbs in the tx path so that the offloads are not needed in the driver. Aside from making it easier to deal with vif type based hardware limitations, this also makes it possible to optimize performance on hardware without native GSO support by declaring GSO support in hw->netdev_features and removing it from vif->netdev_features. This allows mac80211 to handle GSO segmentation after the sta lookup, but before itxq enqueue, thus reducing the number of unnecessary sta lookups, as well as some other per-packet processing. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20221010094338.78070-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: mac80211: update TIM for S1G specification changesKieran Frewen1-5/+9
Updates to the TIM information element to match changes made in the IEEE Std 802.11ah-2020. Signed-off-by: Kieran Frewen <kieran.frewen@morsemicro.com> Co-developed-by: Gilad Itzkovitch <gilad.itzkovitch@morsemicro.com> Signed-off-by: Gilad Itzkovitch <gilad.itzkovitch@morsemicro.com> Link: https://lore.kernel.org/r/20221106221602.25714-1-gilad.itzkovitch@morsemicro.com [use skb_put_data/skb_put_u8] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: mac80211: don't parse multi-BSSID in assoc respJohannes Berg1-1/+1
It's not valid to have the multiple BSSID element in the association response (per 802.11 REVme D1.0), so don't try to parse it there, but only in the fallback beacon elements if needed. The other case that was parsing association requests was already changed in a previous commit. Change-Id: I659d2ef1253e079cc71c46a017044e116e31c024 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: cfg80211: use bss_from_pub() instead of container_of()Johannes Berg1-30/+11
There's no need to open-code container_of() when we have bss_from_pub(). Use it. Change-Id: I074723717909ba211a40e6499f0c36df0e2ba4be Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: mac80211: remove unnecessary synchronize_net()Johannes Berg1-2/+1
The call to ieee80211_do_stop() right after will also do synchronize_rcu() to ensure the SDATA_STATE_RUNNING bit is cleared, so we don't need to synchronize_net() here. Change-Id: Id9f9ffcf195002013e5d9fde288877d219780864 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: mac80211: Drop not needed check for NULLAlexander Wetzel1-1/+1
ieee80211_get_txq() can only be called with vif != NULL. Remove not needed NULL test in function. Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/20221107161328.2883-1-alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: cfg80211: Fix not unregister reg_pdev when load_builtin_regdb_keys() failsChen Zhongjin1-1/+3
In regulatory_init_db(), when it's going to return a error, reg_pdev should be unregistered. When load_builtin_regdb_keys() fails it doesn't do it and makes cfg80211 can't be reload with report: sysfs: cannot create duplicate filename '/devices/platform/regulatory.0' ... <TASK> dump_stack_lvl+0x79/0x9b sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x22d/0x290 kobject_add_internal+0x247/0x800 kobject_add+0x135/0x1b0 device_add+0x389/0x1be0 platform_device_add+0x28f/0x790 platform_device_register_full+0x376/0x4b0 regulatory_init+0x9a/0x4b2 [cfg80211] cfg80211_init+0x84/0x113 [cfg80211] ... Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking") Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com> Link: https://lore.kernel.org/r/20221109090237.214127-1-chenzhongjin@huawei.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: cfg80211: fix comparison of BSS frequenciesJUN-KYU SHIN1-1/+2
If the "channel->freq_offset" comparison is omitted in cmp_bss(), BSS with different kHz units cannot be distinguished in the S1G Band. So "freq_offset" should also be included in the comparison. Signed-off-by: JUN-KYU SHIN <jk.shin@newratek.com> Link: https://lore.kernel.org/r/20221111023301.6395-1-jk.shin@newratek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: mac80211: fix maybe-unused warningÍñigo Huguet1-1/+1
In ieee80211_lookup_key, the variable named `local` is unused if compiled without lockdep, getting this warning: net/mac80211/cfg.c: In function ‘ieee80211_lookup_key’: net/mac80211/cfg.c:542:26: error: unused variable ‘local’ [-Werror=unused-variable] struct ieee80211_local *local = sdata->local; ^~~~~ Fix it with __maybe_unused. Fixes: 8cbf0c2ab6df ("wifi: mac80211: refactor some key code") Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/r/20221111153622.29016-1-ihuguet@redhat.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: cfg80211: Correct example of ieee80211_iface_limitPhilipp Hortmann1-1/+1
Correct wrong closing bracket. Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Link: https://lore.kernel.org/r/20221114200135.GA100176@matrix-ESPRIMO-P710 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: mac80211: fix memory leak in ieee80211_if_add()Zhengchao Shao1-0/+1
When register_netdevice() failed in ieee80211_if_add(), ndev->tstats isn't released. Fix it. Fixes: 5a490510ba5f ("mac80211: use per-CPU TX/RX statistics") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20221117064500.319983-1-shaozhengchao@huawei.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: nl80211: Add checks for nla_nest_start() in nl80211_send_iface()Yuan Can1-0/+3
As the nla_nest_start() may fail with NULL returned, the return value needs to be checked. Fixes: ce08cd344a00 ("wifi: nl80211: expose link information for interfaces") Signed-off-by: Yuan Can <yuancan@huawei.com> Link: https://lore.kernel.org/r/20221129014211.56558-1-yuancan@huawei.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: ieee80211: Do not open-code qos address offsetsKees Cook1-6/+22
When building with -Wstringop-overflow, GCC's KASAN implementation does not correctly perform bounds checking within some complex structures when faced with literal offsets, and can get very confused. For example, this warning is seen due to literal offsets into sturct ieee80211_hdr that may or may not be large enough: drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 'iwl_mvm_rx_mpdu_mq': drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:2022:29: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 2022 | *qc &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT; In file included from drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h:32, from drivers/net/wireless/intel/iwlwifi/mvm/sta.h:15, from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:27, from drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:10: drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/rx.h:559:16: note: at offset [78, 166] into destination object 'mpdu_len' of size 2 559 | __le16 mpdu_len; | ^~~~~~~~ Refactor ieee80211_get_qos_ctl() to avoid using literal offsets, requiring the creation of the actual structure that is described in the comments. Explicitly choose the desired offset, making the code more human-readable too. This is one of the last remaining warning to fix before enabling -Wstringop-overflow globally. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 Link: https://github.com/KSPP/linux/issues/181 Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Kalle Valo <kvalo@kernel.org> Cc: Gregory Greenman <gregory.greenman@intel.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221130212641.never.627-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-12-01wifi: rtw89: link rtw89_vif and chanctx stuffsZong-Zhe Yang3-11/+50
First, introduce struct rtw89_sub_entity for chanctx related stuffs. Second, add enum rtw89_sub_entity_idx to rtw89_vif for vif operation to access its/right chanctx stuffs after future multi-channel support. Besides, RTW89_SUB_ENTITY_0 is the default chanctx entry throughout driver, i.e. it's used for things which may not have a target chanctx yet. So, we need to ensure that RTW89_SUB_ENTITY_0 is always working. If there is at least one alive chanctx, then one of them must take RTW89_SUB_ENTITY_0. If no alive chanctx, RTW89_SUB_ENTITY_0 will be filled by rtw89_config_default_chandef(). Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221129083130.45708-7-pkshih@realtek.com
2022-12-01wifi: rtw89: fw: implement MCC related H2CZong-Zhe Yang2-1/+697
These MCC H2C(s) require to wait for MCC C2H to determine if the execution is successful. Through rtw89_wait_for_cond(), we make them wait for either a completion with data from MCC C2H handlers, which calls rtw89_complete_cond(), or timeout. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221129083130.45708-6-pkshih@realtek.com
2022-12-01wifi: rtw89: mac: process MCC related C2HZong-Zhe Yang5-0/+280
Process C2H(s) related to MCC (multi-channel concurrency). These handling, which either call rtw89_complete_cond() or show message in debug mode, can be considered atomic/lock-free. So, they should be safe to be processed directly after C2H pre-check in previous patch. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221129083130.45708-5-pkshih@realtek.com
2022-12-01wifi: rtw89: introduce helpers to wait/complete on conditionZong-Zhe Yang2-0/+60
MCC (multi-channel concurrency) related H2Cs (host to chip commands) require to wait for C2H (chip to host events) responses to judge the execution result and data. We introduce helpers to assist this process. Besides, we would like the helpers to be generic for use in driver even outside of MCC H2C/C2H, so we make a independent patch for them. In the following, I describe the things first. ``` (A) C2H is generated by FW, and then transferred upto driver. Hence, driver cannot get it immediately without a bit waitting/blocking. For this, we choose to use wait_for_completion_*() instead of busy polling. (B) From the driver management perspective, a scenario, e.g. MCC, may have mulitple kind of H2C functions requiring this process to wait for corresponding C2Hs. But, the driver management flow uses mutex to protect each behavior. So, one scenario triggers one H2C function at one time. To avoid rampant instances of struct completion for each H2C function, we choose to use one struct completion with one condition flag for one scenario. (C) C2Hs, which H2Cs will be waitting for, cannot be ordered with driver management flow, i.e. cannot enqueue work to the same ordered workqueue and cannot lock by the same mutex, to prevent H2C side from getting no C2H responses. So, those C2Hs are parsed in interrupt context directly as done in previous commit. (D) Following (C), the above underline H2Cs and C2Hs will be handled in different contexts without sync. So, we use atomic_cmpxchg() to compare and change the condition in atomic. ``` So, we introduce struct rtw89_wait_info which combines struct completion and atomic_t. Then, the below are the descriptions for helper functions. * rtw89_wait_for_cond() to wait for a completion based on a condition. * rtw89_complete_cond() to complete a given condition and carry data. Each rtw89_wait_info instance independently determines the meaning of its waitting conditions. But, RTW89_WAIT_COND_IDLE (UINT_MAX) is reserved. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221129083130.45708-4-pkshih@realtek.com
2022-12-01wifi: rtw89: check if atomic before queuing c2hZong-Zhe Yang4-4/+68
Before queuing C2H work, we check atomicity of the C2H's handler first now. If atomic or lock-free, handle it directly; otherwise, handle it with mutex in work as previous. This prepares for MAC MCC C2Hs which require to be processed directly. And, their handlers will be functions which can be considered atomic. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221129083130.45708-3-pkshih@realtek.com
2022-12-01wifi: rtw89: rfk: rename rtw89_mcc_info to rtw89_rfk_mcc_infoZong-Zhe Yang4-19/+19
The `rtw89_mcc_info mcc` is only for RFK MCC stuffs instead of common MCC management info. Replace it with `rtw89_rfk_mcc_info rfk_mcc` to avoid confusion and reserve `struct rtw89_mcc_info mcc` for MCC management code. (No logic changes.) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221129083130.45708-2-pkshih@realtek.com
2022-12-01wifi: rtw88: 8821c: enable BT device recovery mechanismPing-Ke Shih3-1/+33
8821ce is a combo card, and BT is a USB device that could get card lost during stress test, and need WiFi firmware to detect and recover it, so driver sends a H2C to enable this mechanism. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221128075653.5221-1-pkshih@realtek.com
2022-12-01wifi: rtw89: 8852b: turn off PoP function in monitor modePing-Ke Shih2-0/+9
PoP stands for Packet on Packet that can improve performance in noisy environment, but it could get RX stuck suddenly. In normal mode, firmware can help to resolve the stuck, but firmware doesn't work in monitor mode. Therefore, turn off PoP to avoid RX stuck. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221125072416.94752-4-pkshih@realtek.com
2022-12-01wifi: rtw89: add HE radiotap for monitor modePing-Ke Shih3-1/+41
With basic HE radiotap, we can check data rate in sniffer data. To store the radiotap data, we reserve headroom of aligned 64 bytes, and then update HE radiotap in monitor mode, so it doesn't affect performance in normal mode. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221125072416.94752-3-pkshih@realtek.com
2022-12-01wifi: rtw89: enable mac80211 virtual monitor interfaceZong-Zhe Yang1-0/+6
For running with mac80211 channel context ops and using only as monitor, we need to enable WANT_MONITOR_VIF to let mac80211 process virtual monitor interface. Then, we are able to set channel on the monitor from user space. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221125072416.94752-2-pkshih@realtek.com
2022-12-01wifi: brcmfmac: Check the count value of channel spec to prevent ↵Minsuk Kang1-0/+17
out-of-bounds reads This patch fixes slab-out-of-bounds reads in brcmfmac that occur in brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count value of channel specifications provided by the device is greater than the length of 'list->element[]', decided by the size of the 'list' allocated with kzalloc(). The patch adds checks that make the functions free the buffer and return -EINVAL if that is the case. Note that the negative return is handled by the caller, brcmf_setup_wiphybands() or brcmf_cfg80211_attach(). Found by a modified version of syzkaller. Crash Report from brcmf_construct_chaninfo(): ================================================================== BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430 Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896 CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_setup_wiphybands+0x1238/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_setup_wiphybands+0x290/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888115f24000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1536 bytes inside of 2048-byte region [ffff888115f24000, ffff888115f24800) Memory state around the buggy address: ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Crash Report from brcmf_enable_bw40_2g(): ================================================================== BUG: KASAN: slab-out-of-bounds in brcmf_cfg80211_attach+0x3d11/0x3fd0 Read of size 4 at addr ffff888103787600 by task kworker/0:2/1896 CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_cfg80211_attach+0x3d11/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_cfg80211_attach+0x3302/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888103787000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1536 bytes inside of 2048-byte region [ffff888103787000, ffff888103787800) Memory state around the buggy address: ffff888103787500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888103787580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888103787600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888103787680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888103787700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr> Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221116142952.518241-1-linuxlovemin@yonsei.ac.kr
2022-11-28Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo14-181/+230
ath.git patches for v6.2. Major changes: ath10k * store WLAN firmware version in SMEM image table
2022-11-28wifi: rtw88: fix race condition when doing H2C commandJi-Pin Jou2-5/+8
For SDIO/USB interface, since the tranferring speed is slower than that in PCIE, it may have race condition when the driver sets down H2C command to the FW. In the function rtw_fw_send_h2c_command, before the patch, box_reg is written first, then box_ex_reg is written. FW starts to work and fetch the value of box_ex_reg, when the most significant byte of box_reg(4 bytes) is written. Meanwhile, for SDIO/USB interface, since the transferring speed is slow, the driver is still in writing the new value of box_ex_reg through the bus, and FW may get the wrong value of box_ex_reg at the moment. To prevent the above driver/FW racing situation, box_ex_reg is written first then box_reg. Furthermore, it is written in 4 bytes at a time, instead of written in one byte one by one. It can increase the speed for SDIO/USB interface. Signed-off-by: Ji-Pin Jou <neo_jou@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221124064442.28042-1-pkshih@realtek.com
2022-11-28wifi: b43: remove reference to removed config B43_PCMCIALukas Bulwahn1-7/+3
Commit 399500da18f7 ("ssb: pick PCMCIA host code support from b43 driver") removes the config B43_PCMCIA. Clean up the last reference to this removed config B43_PCMCIA in the b43_print_driverinfo() function. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221122131248.23738-1-lukas.bulwahn@gmail.com
2022-11-28wifi: rtl8xxxu: Fix use after rcu_read_unlock in rtl8xxxu_bss_info_changedBitterblue Smith1-1/+1
Commit a8b5aef2cca1 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width") introduced a line where the pointer returned by ieee80211_find_sta() is used after rcu_read_unlock(). Move rcu_read_unlock() a bit lower to fix this. Fixes: a8b5aef2cca1 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/3c82ad09-7593-3be1-1d2c-e58505fb43cb@gmail.com
2022-11-28wifi: plfxlc: fix potential memory leak in __lf_x_usb_enable_rx()Ziyang Xuan1-0/+1
urbs does not be freed in exception paths in __lf_x_usb_enable_rx(). That will trigger memory leak. To fix it, add kfree() for urbs within "error" label. Compile tested only. Fixes: 68d57a07bfe5 ("wireless: add plfxlc driver for pureLiFi X, XL, XC devices") Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221119051900.1192401-1-william.xuanziyang@huawei.com
2022-11-25wifi: carl9170: Replace zero-length array of trailing structs with flex-arrayKees Cook1-2/+2
Zero-length arrays are deprecated[1] and are being replaced with flexible array members in support of the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing with UBSAN_BOUNDS, and to globally enable -fstrict-flex-arrays=3. Replace zero-length array with flexible-array member. This results in no differences in binary output. [1] https://github.com/KSPP/linux/issues/78 Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20221118211146.never.395-kees@kernel.org
2022-11-25wifi: ath10k: Store WLAN firmware version in SMEM image tableYoughandhar Chintala2-0/+36
In a SoC based solution, it would be useful to know the versions of the various binary firmware blobs the system is running on. On a QCOM based SoC, this info can be obtained from socinfo debugfs infrastructure. For this to work, respective subsystem drivers have to export the firmware version information to an SMEM based version information table. Having firmware version information at one place will help quickly figure out the firmware versions of various subsystems on the device instead of going through builds/logs in an event of a system crash. Fill WLAN firmware version information in SMEM version table to be printed as part of socinfo debugfs infrastructure on a Qualcomm based SoC. This change is applicable only for SNOC/QMI based targets. Example: cat /sys/kernel/debug/qcom_socinfo/cnss/name QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 Signed-off-by: Youghandhar Chintala <quic_youghand@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20221117180534.2267-1-quic_youghand@quicinc.com
2022-11-22wifi: p54: Replace zero-length array of trailing structs with flex-arrayKees Cook1-2/+2
Zero-length arrays are deprecated[1] and are being replaced with flexible array members in support of the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing with UBSAN_BOUNDS, and to globally enable -fstrict-flex-arrays=3. Replace zero-length array with flexible-array member. This results in no differences in binary output (most especially because struct pda_antenna_gain is unused). The struct is kept for future reference. [1] https://github.com/KSPP/linux/issues/78 Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221118234240.gonna.369-kees@kernel.org
2022-11-22wifi: rtw89: fix physts IE page checkZong-Zhe Yang1-1/+1
The index RTW89_PHYSTS_BITMAP_NUM is not a valid physts IE page. So, fix the check condition. Fixes: eb4e52b3f38d ("rtw89: fix incorrect channel info during scan") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221118042322.26794-1-pkshih@realtek.com
2022-11-22wifi: rtw89: avoid inaccessible IO operations during doing change_interface()Ping-Ke Shih3-1/+18
During doing change_interface(), hardware is power-off, so some components are inaccessible and return error. This causes things unexpected, and we don't have a warning message for that. So, ignore some IO operations in this situation, and add a warning message to indicate something wrong. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221117085235.53777-1-pkshih@realtek.com
2022-11-22wifi: rtw89: switch BANDEDGE and TX_SHAPE based on OFDMA trigger frameEric Huang8-1/+146
There are some registers for transmit waveform control, two of them used in this change are for BANDEDGE and TX_SHAPE control. BANDEDGE controls whether to apply band edge filter to transmit waveform. TX_SHAPE controls whether to apply triangular mask to transmit waveform. It is found for some chip, these two should be turned off during OFDMA UL traffic for better performance. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221117063001.42967-3-pkshih@realtek.com
2022-11-22wifi: rtw89: read CFO from FD or preamble CFO field of phy status ie_type 1 ↵Eric Huang6-2/+12
accordingly Add macro to get FD(frequency domain) CFO field from ie_type 1, and correct the naming for preamble CFO field. Each IC could assign the CFO source to either FD CFO or preamble CFO in chip_info. Based on the suggestion from HW designer, rtw8852b and its derived versions will have better CFO tracking performance with FD CFO. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221117063001.42967-2-pkshih@realtek.com
2022-11-22wifi: rtw89: 8852b: correct TX power controlled by BT-coexistencePing-Ke Shih1-15/+15
When coexistence mechanism is under free-run mode, it could adjust WiFi and BT TX power to avoid interference with each other. For other cases, it should keep original TX power from regular predefined tables, so set correct values to 255 for these cases. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221117061832.42057-1-pkshih@realtek.com
2022-11-22wifi: brcmfmac: Use struct_size() in code ralated to struct brcmf_dload_data_leGustavo A. R. Silva1-3/+4
Prefer struct_size() over open-coded versions of idiom: sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count where count is the max number of items the flexible array is supposed to contain. In this particular case, in the open-coded version sizeof(typeof-flex-array-elements) is implicit in _count_ because the type of the flex array data is u8: drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h:941: 941 struct brcmf_dload_data_le { 942 __le16 flag; 943 __le16 dload_type; 944 __le32 len; 945 __le32 crc; 946 u8 data[]; 947 }; Link: https://github.com/KSPP/linux/issues/160 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/41845ad3660ed4375f0c03fd36a67b2e12fafed5.1668548907.git.gustavoars@kernel.org
2022-11-22wifi: brcmfmac: replace one-element array with flexible-array member in ↵Gustavo A. R. Silva2-3/+3
struct brcmf_dload_data_le One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct brcmf_dload_data_le. Important to mention is that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/230 Link: https://github.com/KSPP/linux/issues/79 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/905f5b68cf93c812360d081caae5b15221db09b6.1668548907.git.gustavoars@kernel.org
2022-11-22wifi: brcmfmac: Use struct_size() and array_size() in code ralated to struct ↵Gustavo A. R. Silva1-3/+3
brcmf_gscan_config Prefer struct_size() over open-coded versions of idiom: sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count where count is the max number of items the flexible array is supposed to contain. Also, use array_size() in call to memcpy(). Link: https://github.com/KSPP/linux/issues/160 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/de0226a549c8d000d8974e207ede786220a3df1a.1668466470.git.gustavoars@kernel.org
2022-11-22wifi: brcmfmac: Replace one-element array with flexible-array memberGustavo A. R. Silva2-2/+2
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct brcmf_gscan_config. Important to mention is that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/241 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/7694550aa9a2753a73a687f61af9441c8cf52fd7.1668466470.git.gustavoars@kernel.org
2022-11-18Merge tag 'rxrpc-next-20221116' of ↵David S. Miller3-11/+19
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Fix oops and missing config conditionals The patches that were pulled into net-next previously[1] had some issues that this patchset fixes: (1) Fix missing IPV6 config conditionals. (2) Fix an oops caused by calling udpv6_sendmsg() directly on an AF_INET socket. (3) Fix the validation of network addresses on entry to socket functions so that we don't allow an AF_INET6 address if we've selected an AF_INET transport socket. Link: https://lore.kernel.org/r/166794587113.2389296.16484814996876530222.stgit@warthog.procyon.org.uk/ [1] ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18net: fix napi_disable() logic errorEric Dumazet1-2/+2
Dan reported a new warning after my recent patch: New smatch warnings: net/core/dev.c:6409 napi_disable() error: uninitialized symbol 'new'. Indeed, we must first wait for STATE_SCHED and STATE_NPSVC to be cleared, to make sure @new variable has been initialized properly. Fixes: 4ffa1d1c6842 ("net: adopt try_cmpxchg() in napi_{enable|disable}()") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18rxrpc: uninitialized variable in rxrpc_send_ack_packet()Dan Carpenter1-2/+0
The "pkt" was supposed to have been deleted in a previous patch. It leads to an uninitialized variable bug. Fixes: 72f0c6fb0579 ("rxrpc: Allocate ACK records at proposal and queue for transmission") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18rxrpc: fix rxkad_verify_response()Dan Carpenter1-2/+4
The error handling for if skb_copy_bits() fails was accidentally deleted so the rxkad_decrypt_ticket() function is not called. Fixes: 5d7edbc9231e ("rxrpc: Get rid of the Rx ring") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18net: ethernet: mtk_eth_soc: remove cpu_relax in mtk_pending_workLorenzo Bianconi1-5/+2
Get rid of cpu_relax in mtk_pending_work routine since MTK_RESETTING is set only in mtk_pending_work() and it runs holding rtnl lock Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18net: ethernet: mtk_eth_soc: do not overwrite mtu configuration running reset ↵Lorenzo Bianconi1-19/+34
routine Restore user configured MTU running mtk_hw_init() during tx timeout routine since it will be overwritten after a hw reset. Reported-by: Felix Fietkau <nbd@nbd.name> Fixes: 9ea4d311509f ("net: ethernet: mediatek: add the whole ethernet reset into the reset process") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18net: ipa: avoid a null pointer dereferenceAlex Elder1-3/+6
Dan Carpenter reported that Smatch found an instance where a pointer which had previously been assumed could be null (as indicated by a null check) was later dereferenced without a similar check. In practice this doesn't lead to a problem because currently the pointers used are all non-null. Nevertheless this patch addresses the reported problem. In addition, I spotted another bug that arose in the same commit. When the command to initialize a routing table memory region was added, the number of entries computed for the non-hashed table was wrong (it ended up being a Boolean rather than the count intended). This bug is fixed here as well. Reported-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/kernel-janitors/Y3OOP9dXK6oEydkf@kili Tested-by: Caleb Connolly <caleb.connolly@linaro.com> Fixes: 5cb76899fb47 ("net: ipa: reduce arguments to ipa_table_init_add()") Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18Merge tag 'wireless-next-2022-11-18' of ↵David S. Miller106-1419/+5790
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.2 Second set of patches for v6.2. Only driver patches this time, nothing really special. Unused platform data support was removed from wl1251 and rtw89 got WoWLAN support. Major changes: ath11k * support configuring channel dwell time during scan rtw89 * new dynamic header firmware format support * Wake-over-WLAN support rtl8xxxu * enable IEEE80211_HW_SUPPORT_FAST_XMIT ==================== Signed-off-by: David S. Miller <davem@davemloft.net>