1. 01 Dec, 2022 13 commits
    • Yuan Can's avatar
      wifi: nl80211: Add checks for nla_nest_start() in nl80211_send_iface() · 5cc58b37
      Yuan Can authored
      As the nla_nest_start() may fail with NULL returned, the return value needs
      to be checked.
      
      Fixes: ce08cd34 ("wifi: nl80211: expose link information for interfaces")
      Signed-off-by: default avatarYuan Can <yuancan@huawei.com>
      Link: https://lore.kernel.org/r/20221129014211.56558-1-yuancan@huawei.comSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5cc58b37
    • Kees Cook's avatar
      wifi: ieee80211: Do not open-code qos address offsets · 278ab979
      Kees Cook authored
      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: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20221130212641.never.627-kees@kernel.orgSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      278ab979
    • Zong-Zhe Yang's avatar
      wifi: rtw89: link rtw89_vif and chanctx stuffs · 75ee07b0
      Zong-Zhe Yang authored
      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: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221129083130.45708-7-pkshih@realtek.com
      75ee07b0
    • Zong-Zhe Yang's avatar
      wifi: rtw89: fw: implement MCC related H2C · c008c4b0
      Zong-Zhe Yang authored
      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: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221129083130.45708-6-pkshih@realtek.com
      c008c4b0
    • Zong-Zhe Yang's avatar
      wifi: rtw89: mac: process MCC related C2H · ef9dff4c
      Zong-Zhe Yang authored
      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: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221129083130.45708-5-pkshih@realtek.com
      ef9dff4c
    • Zong-Zhe Yang's avatar
      wifi: rtw89: introduce helpers to wait/complete on condition · 22b10cdb
      Zong-Zhe Yang authored
      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: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221129083130.45708-4-pkshih@realtek.com
      22b10cdb
    • Zong-Zhe Yang's avatar
      wifi: rtw89: check if atomic before queuing c2h · 860e8263
      Zong-Zhe Yang authored
      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: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221129083130.45708-3-pkshih@realtek.com
      860e8263
    • Zong-Zhe Yang's avatar
      wifi: rtw89: rfk: rename rtw89_mcc_info to rtw89_rfk_mcc_info · 38f25dec
      Zong-Zhe Yang authored
      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: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221129083130.45708-2-pkshih@realtek.com
      38f25dec
    • Ping-Ke Shih's avatar
      wifi: rtw88: 8821c: enable BT device recovery mechanism · 7c57d3dc
      Ping-Ke Shih authored
      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: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221128075653.5221-1-pkshih@realtek.com
      7c57d3dc
    • Ping-Ke Shih's avatar
      wifi: rtw89: 8852b: turn off PoP function in monitor mode · a215b2b7
      Ping-Ke Shih authored
      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: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221125072416.94752-4-pkshih@realtek.com
      a215b2b7
    • Ping-Ke Shih's avatar
      wifi: rtw89: add HE radiotap for monitor mode · 51e8ed4e
      Ping-Ke Shih authored
      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: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221125072416.94752-3-pkshih@realtek.com
      51e8ed4e
    • Zong-Zhe Yang's avatar
      wifi: rtw89: enable mac80211 virtual monitor interface · cd9b6b3b
      Zong-Zhe Yang authored
      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: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221125072416.94752-2-pkshih@realtek.com
      cd9b6b3b
    • Minsuk Kang's avatar
      wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads · 4920ab13
      Minsuk Kang authored
      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: default avatarDokyung Song <dokyungs@yonsei.ac.kr>
      Reported-by: default avatarJisoo Jang <jisoo.jang@yonsei.ac.kr>
      Reported-by: default avatarMinsuk Kang <linuxlovemin@yonsei.ac.kr>
      Reviewed-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarMinsuk Kang <linuxlovemin@yonsei.ac.kr>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20221116142952.518241-1-linuxlovemin@yonsei.ac.kr
      4920ab13
  2. 28 Nov, 2022 5 commits
  3. 25 Nov, 2022 2 commits
  4. 22 Nov, 2022 10 commits
  5. 18 Nov, 2022 10 commits