linux-stable.git/drivers/net/wireless, branch v6.3.4

wifi: rtw88: correct qsel_to_ep[] type as int

2023-05-24T16:30:21+00:00

commit 8e4942db5f5ed7b7d9690d93235b3ca49c5c59ce upstream.

qsel_to_ep[] can be assigned negative value, so change type from 'u8' to
'int'. Otherwise, Smatch static checker warns:
  drivers/net/wireless/realtek/rtw88/usb.c:219 rtw_usb_parse() warn:
  assigning (-22) to unsigned variable 'rtwusb->qsel_to_ep[8]'

Cc: stable@vger.kernel.org
Fixes: a6f187f92bcc ("wifi: rtw88: usb: fix priority queue to endpoint mapping")
Reported-by: Dan Carpenter 
Link: https://lore.kernel.org/linux-wireless/c3f70197-829d-48ed-ae15-66a9de80fa90@kili.mountain/
Cc: Sascha Hauer 
Signed-off-by: Ping-Ke Shih 
Acked-by: Sascha Hauer 
Tested-by: Larry Finger 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230508085539.46795-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: use work to update rate to avoid RCU warning

2023-05-24T16:30:21+00:00

commit bcafcb959a57a6890e900199690c5fc47da1a304 upstream.

The ieee80211_ops::sta_rc_update must be atomic, because
ieee80211_chan_bw_change() holds rcu_read lock while calling
drv_sta_rc_update(), so create a work to do original things.

 Voluntary context switch within RCU read-side critical section!
 WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318
 rcu_note_context_switch+0x571/0x5d0
 CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G        W  OE
 Workqueue: phy3 ieee80211_chswitch_work [mac80211]
 RIP: 0010:rcu_note_context_switch+0x571/0x5d0
 Call Trace:
  
  __schedule+0xb0/0x1460
  ? __mod_timer+0x116/0x360
  schedule+0x5a/0xc0
  schedule_timeout+0x87/0x150
  ? trace_raw_output_tick_stop+0x60/0x60
  wait_for_completion_timeout+0x7b/0x140
  usb_start_wait_urb+0x82/0x160 [usbcore
  usb_control_msg+0xe3/0x140 [usbcore
  rtw_usb_read+0x88/0xe0 [rtw_usb
  rtw_usb_read8+0xf/0x10 [rtw_usb
  rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core
  rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core
  drv_sta_rc_update+0x7c/0x160 [mac80211
  ieee80211_chan_bw_change+0xfb/0x110 [mac80211
  ieee80211_change_chanctx+0x38/0x130 [mac80211
  ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211
  ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211
  ieee80211_chswitch_work+0x95/0x170 [mac80211
  process_one_work+0x201/0x410
  worker_thread+0x4a/0x3b0
  ? process_one_work+0x410/0x410
  kthread+0xe1/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x1f/0x30
  

Cc: stable@vger.kernel.org
Fixes: c1edc86472fc ("rtw88: add ieee80211:sta_rc_update ops")
Reported-by: Larry Finger 
Link: https://lore.kernel.org/linux-wireless/f1e31e8e-f84e-3791-50fb-663a83c5c6e9@lwfinger.net/T/#t
Signed-off-by: Ping-Ke Shih 
Tested-by: Larry Finger 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230508085429.46653-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman

wifi: brcmfmac: Check for probe() id argument being NULL

2023-05-24T16:30:21+00:00

commit 60fc756fc8e6954a5618eecac73b255d651602e4 upstream.

The probe() id argument may be NULL in 2 scenarios:

1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe
   the device.

2. If a user tries to manually bind the driver from sysfs then the sdio /
   pcie / usb probe() function gets called with NULL as id argument.

1. Is being hit by users causing the following oops on resume and causing
wifi to stop working:

BUG: kernel NULL pointer dereference, address: 0000000000000018

Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020
Workgueue: events_unbound async_run_entry_fn
RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]

Call Trace:
 
 brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]
 ? pci_pm_resume+0x5b/0xf0
 ? pci_legacy_resume+0x80/0x80
 dpm_run_callback+0x47/0x150
 device_resume+0xa2/0x1f0
 async_resume+0x1d/0x30


Fix this by checking for id being NULL.

In the PCI and USB cases try a manual lookup of the id so that manually
binding the driver through sysfs and more importantly brcmf_pcie_probe()
on resume will work.

For the SDIO case there is no helper to do a manual sdio_device_id lookup,
so just directly error out on a NULL id there.

Fixes: da6d9c8ecd00 ("wifi: brcmfmac: add firmware vendor info in driver info")
Reported-by: Felix 
Link: https://lore.kernel.org/regressions/4ef3f252ff530cbfa336f5a0d80710020fc5cb1e.camel@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Reviewed-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230510141856.46532-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman

wifi: iwlwifi: mvm: don't trust firmware n_channels

2023-05-24T16:30:18+00:00

[ Upstream commit 682b6dc29d98e857e6ca4bbc077c7dc2899b7473 ]

If the firmware sends us a corrupted MCC response with
n_channels much larger than the command response can be,
we might copy far too much (uninitialized) memory and
even crash if the n_channels is large enough to make it
run out of the one page allocated for the FW response.

Fix that by checking the lengths. Doing a < comparison
would be sufficient, but the firmware should be doing
it correctly, so check more strictly.

Fixes: dcaf9f5ecb6f ("iwlwifi: mvm: add MCC update FW API")
Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230514120631.d7b233139eb4.I51fd319df8e9d41881fc8450e83d78049518a79a@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: fix OEM's name in the tas approved list

2023-05-24T16:30:18+00:00

[ Upstream commit d0246a0e49efee0f8649d0e4f2350614cdfe6565 ]

Fix a spelling mistake.

Fixes: 2856f623ce48 ("iwlwifi: mvm: Add list of OEMs allowed to use TAS")
Signed-off-by: Alon Giladi 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230514120631.4090de6d1878.If9391ef6da78f1b2cc5eb6cb8f6965816bb7a7f5@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: iwlwifi: fix OEM's name in the ppag approved list

2023-05-24T16:30:18+00:00

[ Upstream commit eca7296d9a671e9961834d2ace9cc0ce21fc15b3 ]

Fix a spelling mistake.

Fixes: e8e10a37c51c ("iwlwifi: acpi: move ppag code from mvm to fw/acpi")
Signed-off-by: Alon Giladi 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230514120631.fdd07f36a8bf.I223e5fb16ab5c95d504c3fdaffd0bd70affad1c2@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: iwlwifi: fw: fix DBGI dump

2023-05-24T16:30:18+00:00

[ Upstream commit d3ae69180bbd74bcbc03a2b6d10ed7eccbe98c23 ]

The DBGI dump is (unsurprisingly) of type DBGI, not SRAM.
This leads to bad register accesses because the union is
built differently, there's no allocation ID, and thus the
allocation ID ends up being 0x8000.

Note that this was already wrong for DRAM vs. SMEM since
they use different parts of the union, but the allocation
ID is at the same place, so it worked.

Fix all of this but set the allocation ID in a way that
the offset calculation ends up without any offset.

Fixes: 34bc27783a31 ("iwlwifi: yoyo: fix DBGI_SRAM ini dump header.")
Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230514120631.19a302ae4c65.I12272599f7c1930666157b9d5e7f81fe9ec4c421@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: fix cancel_delayed_work_sync() deadlock

2023-05-24T16:30:17+00:00

[ Upstream commit c2d8b7f257b2398f2d866205365895e038beca12 ]

Lockdep points out that we can deadlock here by calling
cancel_delayed_work_sync() because that might be already
running and gotten interrupted by the NAPI soft-IRQ.
Even just calling something that can sleep is wrong in
this context though.

Luckily, it doesn't even really matter since the things
we need to do are idempotent, so just drop the _sync().

Fixes: e5d153ec54f0 ("iwlwifi: mvm: fix CSA AP side")
Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230514120631.b1813c823b4d.I9d20cc06d24fa40b6774d3dd95ea5e2bf8dd015b@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

wifi: mt76: connac: fix stats->tx_bytes calculation

2023-05-24T16:30:14+00:00

[ Upstream commit c7ab7a29ef5c0779574120d922256ce4651555d3 ]

The stats->tx_bytes shall subtract retry byte from tx byte.

Fixes: 43eaa3689507 ("wifi: mt76: add PPDU based TxS support for WED device")
Signed-off-by: Ryder Lee 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/b3cd45596943cf5a06b2e08e2fe732ab0b51311b.1682285873.git.ryder.lee@mediatek.com
Signed-off-by: Sasha Levin

wifi: rtw88: Fix memory leak in rtw88_usb

2023-05-24T16:30:07+00:00

[ Upstream commit 59a3a312009723e3e5082899655fdcc420e2b47a ]

Kmemleak shows the following leak arising from routine in the usb
probe routine:

unreferenced object 0xffff895cb29bba00 (size 512):
  comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s)
  hex dump (first 32 bytes):
    77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00  w000...../-+0...
    02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00  ..*(.....U......
  backtrace:
    [] kmalloc_trace+0x26/0x90
    [] rtw_usb_probe+0x2f1/0x680 [rtw_usb]
    [] usb_probe_interface+0xdd/0x2e0 [usbcore]
    [] really_probe+0x18e/0x3d0
    [] __driver_probe_device+0x78/0x160
    [] driver_probe_device+0x1f/0x90
    [] __driver_attach+0xbf/0x1b0
    [] bus_for_each_dev+0x70/0xc0
    [] bus_add_driver+0x10e/0x210
    [] driver_register+0x55/0xf0
    [] usb_register_driver+0x88/0x140 [usbcore]
    [] do_one_initcall+0x43/0x210
    [] do_init_module+0x4a/0x200
    [] __do_sys_finit_module+0xac/0x120
    [] do_syscall_64+0x56/0x80
    [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

The leak was verified to be real by unloading the driver, which resulted
in a dangling pointer to the allocation.

The allocated memory is freed in rtw_usb_intf_deinit().

Signed-off-by: Larry Finger 
Cc: Sascha Hauer 
Cc: Ping-Ke Shih 
Reviewed-by: Ping-Ke Shih 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20230417160331.23071-1-Larry.Finger@lwfinger.net
Signed-off-by: Sasha Levin