1. 15 Mar, 2023 24 commits
  2. 13 Mar, 2023 16 commits
    • Kalle Valo's avatar
      Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git · 4c4ca9f7
      Kalle Valo authored
      ath.git patches for v6.4. Major changes:
      
      ath10k
      
      * enable threaded napi on WCN3990
      
      ath11k
      
      * push MU-MIMO params from hostapd to hardware
      
      * tx ack signal support for management packets
      4c4ca9f7
    • Jisoo Jang's avatar
      wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() · 0da40e01
      Jisoo Jang authored
      Fix a slab-out-of-bounds read that occurs in kmemdup() called from
      brcmf_get_assoc_ies().
      The bug could occur when assoc_info->req_len, data from a URB provided
      by a USB device, is bigger than the size of buffer which is defined as
      WL_EXTRA_BUF_MAX.
      
      Add the size check for req_len/resp_len of assoc_info.
      
      Found by a modified version of syzkaller.
      
      [   46.592467][    T7] ==================================================================
      [   46.594687][    T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50
      [   46.596572][    T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7
      [   46.598575][    T7]
      [   46.599157][    T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G           O      5.14.0+ #145
      [   46.601333][    T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      [   46.604360][    T7] Workqueue: events brcmf_fweh_event_worker
      [   46.605943][    T7] Call Trace:
      [   46.606584][    T7]  dump_stack_lvl+0x8e/0xd1
      [   46.607446][    T7]  print_address_description.constprop.0.cold+0x93/0x334
      [   46.608610][    T7]  ? kmemdup+0x3e/0x50
      [   46.609341][    T7]  kasan_report.cold+0x79/0xd5
      [   46.610151][    T7]  ? kmemdup+0x3e/0x50
      [   46.610796][    T7]  kasan_check_range+0x14e/0x1b0
      [   46.611691][    T7]  memcpy+0x20/0x60
      [   46.612323][    T7]  kmemdup+0x3e/0x50
      [   46.612987][    T7]  brcmf_get_assoc_ies+0x967/0xf60
      [   46.613904][    T7]  ? brcmf_notify_vif_event+0x3d0/0x3d0
      [   46.614831][    T7]  ? lock_chain_count+0x20/0x20
      [   46.615683][    T7]  ? mark_lock.part.0+0xfc/0x2770
      [   46.616552][    T7]  ? lock_chain_count+0x20/0x20
      [   46.617409][    T7]  ? mark_lock.part.0+0xfc/0x2770
      [   46.618244][    T7]  ? lock_chain_count+0x20/0x20
      [   46.619024][    T7]  brcmf_bss_connect_done.constprop.0+0x241/0x2e0
      [   46.620019][    T7]  ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0
      [   46.620818][    T7]  ? __lock_acquire+0x181f/0x5790
      [   46.621462][    T7]  brcmf_notify_connect_status+0x448/0x1950
      [   46.622134][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
      [   46.622736][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
      [   46.623390][    T7]  ? find_held_lock+0x2d/0x110
      [   46.623962][    T7]  ? brcmf_fweh_event_worker+0x19f/0xc60
      [   46.624603][    T7]  ? mark_held_locks+0x9f/0xe0
      [   46.625145][    T7]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
      [   46.625871][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
      [   46.626545][    T7]  brcmf_fweh_call_event_handler.isra.0+0x90/0x100
      [   46.627338][    T7]  brcmf_fweh_event_worker+0x557/0xc60
      [   46.627962][    T7]  ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
      [   46.628736][    T7]  ? rcu_read_lock_sched_held+0xa1/0xd0
      [   46.629396][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
      [   46.629970][    T7]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
      [   46.630649][    T7]  process_one_work+0x92b/0x1460
      [   46.631205][    T7]  ? pwq_dec_nr_in_flight+0x330/0x330
      [   46.631821][    T7]  ? rwlock_bug.part.0+0x90/0x90
      [   46.632347][    T7]  worker_thread+0x95/0xe00
      [   46.632832][    T7]  ? __kthread_parkme+0x115/0x1e0
      [   46.633393][    T7]  ? process_one_work+0x1460/0x1460
      [   46.633957][    T7]  kthread+0x3a1/0x480
      [   46.634369][    T7]  ? set_kthread_struct+0x120/0x120
      [   46.634933][    T7]  ret_from_fork+0x1f/0x30
      [   46.635431][    T7]
      [   46.635687][    T7] Allocated by task 7:
      [   46.636151][    T7]  kasan_save_stack+0x1b/0x40
      [   46.636628][    T7]  __kasan_kmalloc+0x7c/0x90
      [   46.637108][    T7]  kmem_cache_alloc_trace+0x19e/0x330
      [   46.637696][    T7]  brcmf_cfg80211_attach+0x4a0/0x4040
      [   46.638275][    T7]  brcmf_attach+0x389/0xd40
      [   46.638739][    T7]  brcmf_usb_probe+0x12de/0x1690
      [   46.639279][    T7]  usb_probe_interface+0x2aa/0x760
      [   46.639820][    T7]  really_probe+0x205/0xb70
      [   46.640342][    T7]  __driver_probe_device+0x311/0x4b0
      [   46.640876][    T7]  driver_probe_device+0x4e/0x150
      [   46.641445][    T7]  __device_attach_driver+0x1cc/0x2a0
      [   46.642000][    T7]  bus_for_each_drv+0x156/0x1d0
      [   46.642543][    T7]  __device_attach+0x23f/0x3a0
      [   46.643065][    T7]  bus_probe_device+0x1da/0x290
      [   46.643644][    T7]  device_add+0xb7b/0x1eb0
      [   46.644130][    T7]  usb_set_configuration+0xf59/0x16f0
      [   46.644720][    T7]  usb_generic_driver_probe+0x82/0xa0
      [   46.645295][    T7]  usb_probe_device+0xbb/0x250
      [   46.645786][    T7]  really_probe+0x205/0xb70
      [   46.646258][    T7]  __driver_probe_device+0x311/0x4b0
      [   46.646804][    T7]  driver_probe_device+0x4e/0x150
      [   46.647387][    T7]  __device_attach_driver+0x1cc/0x2a0
      [   46.647926][    T7]  bus_for_each_drv+0x156/0x1d0
      [   46.648454][    T7]  __device_attach+0x23f/0x3a0
      [   46.648939][    T7]  bus_probe_device+0x1da/0x290
      [   46.649478][    T7]  device_add+0xb7b/0x1eb0
      [   46.649936][    T7]  usb_new_device.cold+0x49c/0x1029
      [   46.650526][    T7]  hub_event+0x1c98/0x3950
      [   46.650975][    T7]  process_one_work+0x92b/0x1460
      [   46.651535][    T7]  worker_thread+0x95/0xe00
      [   46.651991][    T7]  kthread+0x3a1/0x480
      [   46.652413][    T7]  ret_from_fork+0x1f/0x30
      [   46.652885][    T7]
      [   46.653131][    T7] The buggy address belongs to the object at ffff888019442000
      [   46.653131][    T7]  which belongs to the cache kmalloc-2k of size 2048
      [   46.654669][    T7] The buggy address is located 0 bytes inside of
      [   46.654669][    T7]  2048-byte region [ffff888019442000, ffff888019442800)
      [   46.656137][    T7] The buggy address belongs to the page:
      [   46.656720][    T7] page:ffffea0000651000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x19440
      [   46.657792][    T7] head:ffffea0000651000 order:3 compound_mapcount:0 compound_pincount:0
      [   46.658673][    T7] flags: 0x100000000010200(slab|head|node=0|zone=1)
      [   46.659422][    T7] raw: 0100000000010200 0000000000000000 dead000000000122 ffff888100042000
      [   46.660363][    T7] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
      [   46.661236][    T7] page dumped because: kasan: bad access detected
      [   46.661956][    T7] page_owner tracks the page as allocated
      [   46.662588][    T7] page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 7, ts 31136961085, free_ts 0
      [   46.664271][    T7]  prep_new_page+0x1aa/0x240
      [   46.664763][    T7]  get_page_from_freelist+0x159a/0x27c0
      [   46.665340][    T7]  __alloc_pages+0x2da/0x6a0
      [   46.665847][    T7]  alloc_pages+0xec/0x1e0
      [   46.666308][    T7]  allocate_slab+0x380/0x4e0
      [   46.666770][    T7]  ___slab_alloc+0x5bc/0x940
      [   46.667264][    T7]  __slab_alloc+0x6d/0x80
      [   46.667712][    T7]  kmem_cache_alloc_trace+0x30a/0x330
      [   46.668299][    T7]  brcmf_usbdev_qinit.constprop.0+0x50/0x470
      [   46.668885][    T7]  brcmf_usb_probe+0xc97/0x1690
      [   46.669438][    T7]  usb_probe_interface+0x2aa/0x760
      [   46.669988][    T7]  really_probe+0x205/0xb70
      [   46.670487][    T7]  __driver_probe_device+0x311/0x4b0
      [   46.671031][    T7]  driver_probe_device+0x4e/0x150
      [   46.671604][    T7]  __device_attach_driver+0x1cc/0x2a0
      [   46.672192][    T7]  bus_for_each_drv+0x156/0x1d0
      [   46.672739][    T7] page_owner free stack trace missing
      [   46.673335][    T7]
      [   46.673620][    T7] Memory state around the buggy address:
      [   46.674213][    T7]  ffff888019442700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   46.675083][    T7]  ffff888019442780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   46.675994][    T7] >ffff888019442800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   46.676875][    T7]                    ^
      [   46.677323][    T7]  ffff888019442880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   46.678190][    T7]  ffff888019442900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   46.679052][    T7] ==================================================================
      [   46.679945][    T7] Disabling lock debugging due to kernel taint
      [   46.680725][    T7] Kernel panic - not syncing:
      Reviewed-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarJisoo Jang <jisoo.jang@yonsei.ac.kr>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230309104457.22628-1-jisoo.jang@yonsei.ac.kr
      0da40e01
    • Dongliang Mu's avatar
      wifi: rtw88: fix memory leak in rtw_usb_probe() · 48181d28
      Dongliang Mu authored
      drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()
      warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811
      
      Fix this by modifying return to a goto statement.
      Signed-off-by: default avatarDongliang Mu <dzm91@hust.edu.cn>
      Reviewed-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230309021636.528601-1-dzm91@hust.edu.cn
      48181d28
    • Ching-Te Ku's avatar
      wifi: rtw89: coex: Add v5 firmware cycle status report · 3ab7f9b9
      Ching-Te Ku authored
      To support v5 version firmware cycle report, apply the related structure
      and functions. v5 cycle report add a group of status to show how the
      free-run/TDMA training goes to. It is a firmware mechanism that can auto
      adjust coexistence mode between TDMA and free run mechanism at 3 antenna
      solution. v5 version provide more reference data to let the mechanism
      make decision.
      Signed-off-by: default avatarChing-Te Ku <ku920601@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/20230308053225.24377-8-pkshih@realtek.com
      3ab7f9b9
    • Ching-Te Ku's avatar
      wifi: rtw89: coex: Add v2 Bluetooth scan info · 262cc19e
      Ching-Te Ku authored
      Compare to v1 and v2 removed some not usable parameters. Save firmware
      code size. The information can show how frequent and how long the
      Bluetooth scan do. It will help to debug coexistence issue.
      Signed-off-by: default avatarChing-Te Ku <ku920601@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/20230308053225.24377-7-pkshih@realtek.com
      262cc19e
    • Ching-Te Ku's avatar
      wifi: rtw89: coex: Fix wrong structure assignment at null data report · 9dfa09e0
      Ching-Te Ku authored
      Correct pointer assignment of v1 null data report. It doesn't really
      change logic at all, but it looks more readable.
      Signed-off-by: default avatarChing-Te Ku <ku920601@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/20230308053225.24377-6-pkshih@realtek.com
      9dfa09e0
    • Ching-Te Ku's avatar
      wifi: rtw89: coex: Add register monitor report v2 format · e5e52feb
      Ching-Te Ku authored
      The v2 firmware report reduce its maximum register numbers from 30 to 20,
      it can help to save firmware code size.
      Signed-off-by: default avatarChing-Te Ku <ku920601@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/20230308053225.24377-5-pkshih@realtek.com
      e5e52feb
    • Ching-Te Ku's avatar
      wifi: rtw89: coex: Add traffic TX/RX info and its H2C · a2c0ce5d
      Ching-Te Ku authored
      There is a new mechanism which can do some real time performance
      tuning for WiFi and BT. This TX/RX info is a condition provide to
      firmware to do traffic analysis.
      Signed-off-by: default avatarChing-Te Ku <ku920601@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/20230308053225.24377-4-pkshih@realtek.com
      a2c0ce5d
    • Ching-Te Ku's avatar
      wifi: rtw89: coex: Add WiFi role info v2 · 5049964c
      Ching-Te Ku authored
      Remove WiFi traffic busy level & traffic rate from active role information.
      This information will move to v5 version TDMA cycle info.
      Signed-off-by: default avatarChing-Te Ku <ku920601@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/20230308053225.24377-3-pkshih@realtek.com
      5049964c
    • Ching-Te Ku's avatar
      wifi: rtw89: coex: Add more error_map and counter to log · e49bdd85
      Ching-Te Ku authored
      The error map and counter can help to analyze is coexistence mechanism
      going well or not. For example, if there is E2G (External control Wi-Fi
      slot for Wi-Fi 2.4 GHz) hang counter, it means Wi-Fi firmware didn't cut
      a slot for Wi-Fi 2.4 GHz. Maybe something wrong with firmware timer.
      Signed-off-by: default avatarChing-Te Ku <ku920601@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/20230308053225.24377-2-pkshih@realtek.com
      e49bdd85
    • Jacob Keller's avatar
      wifi: qtnfmac: use struct_size and size_sub for payload length · 84e9e210
      Jacob Keller authored
      Replace the calculations for the payload length in
      qtnf_cmd_band_fill_iftype with struct_size() and size_sub(). While
      the payload length does not get directly passed to an allocation function,
      the performed calculation is still calculating the size of a flexible array
      structure (minus the size of a header structure).
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Cc: Igor Mitsyanko <imitsyanko@quantenna.com>
      Cc: Sergey Matyukevich <geomatsi@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230307230212.3735818-1-jacob.e.keller@intel.com
      84e9e210
    • Jacob Keller's avatar
      wifi: ipw2x00: convert ipw_fw_error->elem to flexible array[] · a23c82e0
      Jacob Keller authored
      The ipw_fw_error structure contains a payload[] flexible array as well as
      two pointers to this array area, ->elem, and ->log. The total size of the
      allocated structure is computed without use of the <linux/overflow.h>
      macros.
      
      There's no reason to keep both a payload[] and an extra pointer to both the
      elem and log members. Convert the elem pointer member into the flexible
      array member, removing payload.
      
      Fix the allocation of the ipw_fw_error structure to use size_add(),
      struct_size(), and array_size() to compute the allocation. This ensures
      that any overflow saturates at SIZE_MAX rather than overflowing and
      potentially allowing an undersized allocation.
      
      Before the structure change, the layout of ipw_fw_error was:
      
      struct ipw_fw_error {
              long unsigned int          jiffies;              /*     0     8 */
              u32                        status;               /*     8     4 */
              u32                        config;               /*    12     4 */
              u32                        elem_len;             /*    16     4 */
              u32                        log_len;              /*    20     4 */
              struct ipw_error_elem *    elem;                 /*    24     8 */
              struct ipw_event *         log;                  /*    32     8 */
              u8                         payload[];            /*    40     0 */
      
              /* size: 40, cachelines: 1, members: 8 */
              /* last cacheline: 40 bytes */
      };
      
      After this change, the layout is now:
      
      struct ipw_fw_error {
              long unsigned int          jiffies;              /*     0     8 */
              u32                        status;               /*     8     4 */
              u32                        config;               /*    12     4 */
              u32                        elem_len;             /*    16     4 */
              u32                        log_len;              /*    20     4 */
              struct ipw_event *         log;                  /*    24     8 */
              struct ipw_error_elem      elem[];               /*    32     0 */
      
              /* size: 32, cachelines: 1, members: 7 */
              /* last cacheline: 32 bytes */
      };
      
      This saves a total of 8 bytes for every ipw_fw_error allocation, and
      removes the risk of a potential overflow on the allocation.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230307230148.3735684-1-jacob.e.keller@intel.com
      a23c82e0
    • Martin Kaiser's avatar
      wifi: rtl8xxxu: use module_usb_driver · 0606b344
      Martin Kaiser authored
      We can use the module_usb_driver macro instead of open-coding the driver's
      init and exit functions. This is simpler and saves some lines of code.
      Other realtek wireless drivers use module_usb_driver as well.
      Signed-off-by: default avatarMartin Kaiser <martin@kaiser.cx>
      Reviewed-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230307195718.168021-1-martin@kaiser.cx
      0606b344
    • Ping-Ke Shih's avatar
      wifi: rtw89: release RX standby timer of beamformee CSI to save power · 8a66293e
      Ping-Ke Shih authored
      Originally, we keep RX standby timer to handle beamformee CSI, but this
      spends power and causes system not entering power save mode. To improve
      power consumption, release the timer if throughput becomes low.
      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/20230307141848.26403-1-pkshih@realtek.com
      8a66293e
    • Martin Kaiser's avatar
      wifi: rtl8xxxu: mark Edimax EW-7811Un V2 as tested · df259fc1
      Martin Kaiser authored
      The Edimax V2 (vid 0x7392, pid 0xb811) works well with the rtl8xxxu driver
      since rtl8188eu support has been added. Remove the untested flag for this
      device.
      Signed-off-by: default avatarMartin Kaiser <martin@kaiser.cx>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230305175932.719103-1-martin@kaiser.cx
      df259fc1
    • Hans de Goede's avatar
      wifi: brcmfmac: Use ISO3166 country code and rev 0 as fallback on 4356 · 659fda7f
      Hans de Goede authored
      Many devices ship with a nvram ccode value of X2/XT/XU/XV/ALL which are
      all special world-wide compatibility ccode-s. Most of these world-wide
      ccode-s allow passive scan mode only for 2.4GHz channels 12-14,
      only enabling them when an AP is seen on them.
      
      Since linux-firmware has moved to the new cyfmac4356-pci.bin +
      cyfmac4356-pci.clm_blob firmware files this no longer works and
      4356 devices using e.g. an X2 ccode fail to connect to an AP on
      channel 13.
      
      Add the 4356 chip-id to the list of chips for which to use the ISO3166
      country code + rev 0 as fallback in brcmf_translate_country_code() to
      fix this.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230303222331.285663-1-hdegoede@redhat.com
      659fda7f