linux/net/wireless, branch v6.8

wifi: nl80211: reject iftype change with mesh ID change

2024-02-15T10:00:37Z

It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID. Cc: stable@vger.kernel.org Fixes: 29cbe68c516a ("cfg80211/mac80211: add mesh join/leave commands") Reported-by: syzbot+dd4779978217b1973180@syzkaller.appspotmail.com Signed-off-by: Johannes Berg

wifi: cfg80211: detect stuck ECSA element in probe resp

2024-02-02T12:08:58Z

We recently added some validation that we don't try to connect to an AP that is currently in a channel switch process, since that might want the channel to be quiet or we might not be able to connect in time to hear the switching in a beacon. This was in commit c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process"). However, we promptly got a report that this caused new connection failures, and it turns out that the AP that we now cannot connect to is permanently advertising an extended channel switch announcement, even with quiet. The AP in question was an Asus RT-AC53, with firmware 3.0.0.4.380_10760-g21a5898. As a first step, attempt to detect that we're dealing with such a situation, so mac80211 can use this later. Reported-by: coldolt Closes: https://lore.kernel.org/linux-wireless/CAJvGw+DQhBk_mHXeu6RTOds5iramMW2FbMB01VbKRA4YbHHDTA@mail.gmail.com/ Fixes: c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process") Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240129131413.246972c8775e.Ibf834d7f52f9951a353b6872383da710a7358338@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: fix wiphy delayed work queueing

2024-01-26T09:43:32Z

When a wiphy work is queued with timer, and then again without a delay, it's started immediately but *also* started again after the timer expires. This can lead, for example, to warnings in mac80211's offchannel code as reported by Jouni. Running the same work twice isn't expected, of course. Fix this by deleting the timer at this point, when queuing immediately due to delay=0. Cc: stable@vger.kernel.org Reported-by: Jouni Malinen Fixes: a3ee4dc84c4e ("wifi: cfg80211: add a work abstraction with special semantics") Link: https://msgid.link/20240125095108.2feb0eaaa446.I4617f3210ed0e7f252290d5970dac6a876aa595b@changeid Signed-off-by: Johannes Berg

Merge tag 'wireless-2024-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless

2024-01-23T16:38:13Z

Kalle Valo says: ==================== wireless fixes for v6.8-rc2 The most visible fix here is the ath11k crash fix which was introduced in v6.7. We also have a fix for iwlwifi memory corruption and few smaller fixes in the stack. * tag 'wireless-2024-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mac80211: fix race condition on enabling fast-xmit wifi: iwlwifi: fix a memory corruption wifi: mac80211: fix potential sta-link leak wifi: cfg80211/mac80211: remove dependency on non-existing option wifi: cfg80211: fix missing interfaces when dumping wifi: ath11k: rely on mac80211 debugfs handling for vif wifi: p54: fix GCC format truncation warning with wiphy->fw_version ==================== Link: https://lore.kernel.org/r/20240122153434.E0254C433C7@smtp.kernel.org Signed-off-by: Jakub Kicinski

wifi: cfg80211/mac80211: remove dependency on non-existing option

2024-01-18T13:50:01Z

Commit ffbd0c8c1e7f ("wifi: mac80211: add an element parsing unit test") and commit 730eeb17bbdd ("wifi: cfg80211: add first kunit tests, for element defrag") add new configs that depend on !KERNEL_6_2, but the config option KERNEL_6_2 does not exist in the tree. This dependency is used for handling backporting to restrict the option to certain kernels but this really should not be carried around the mainline kernel tree. Clean up this needless dependency on the non-existing option KERNEL_6_2. Link: https://lore.kernel.org/lkml/CAKXUXMyfrM6amOR7Ysim3WNQ-Ckf9HJDqRhAoYmLXujo1UV+yA@mail.gmail.com/ Signed-off-by: Lukas Bulwahn Signed-off-by: Johannes Berg

wifi: cfg80211: fix missing interfaces when dumping

2024-01-18T13:48:11Z

The nl80211_dump_interface() supports resumption in case nl80211_send_iface() doesn't have the resources to complete its work. The logic would store the progress as iteration offsets for rdev and wdev loops. However the logic did not properly handle resumption for non-last rdev. Assuming a system with 2 rdevs, with 2 wdevs each, this could happen: dump(cb=[0, 0]): if_start=cb[1] (=0) send rdev0.wdev0 -> ok send rdev0.wdev1 -> yield cb[1] = 1 dump(cb=[0, 1]): if_start=cb[1] (=1) send rdev0.wdev1 -> ok // since if_start=1 the rdev0.wdev0 got skipped // through if_idx < if_start send rdev1.wdev1 -> ok The if_start needs to be reset back to 0 upon wdev loop end. The problem is actually hard to hit on a desktop, and even on most routers. The prerequisites for this manifesting was: - more than 1 wiphy - a few handful of interfaces - dump without rdev or wdev filter I was seeing this with 4 wiphys 9 interfaces each. It'd miss 6 interfaces from the last wiphy reported to userspace. Signed-off-by: Michal Kazior Link: https://msgid.link/20240116142340.89678-1-kazikcz@gmail.com Signed-off-by: Johannes Berg

Merge tag 'wireless-next-2024-01-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

2024-01-05T01:00:08Z

Johannes Berg says: ==================== Just a couple of more things over the holidays: - first kunit tests for both cfg80211 and mac80211 - a few multi-link fixes - DSCP mapping update - RCU fix * tag 'wireless-next-2024-01-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: wifi: mac80211: remove redundant ML element check wifi: cfg80211: parse all ML elements in an ML probe response wifi: cfg80211: correct comment about MLD ID wifi: cfg80211: Update the default DSCP-to-UP mapping wifi: cfg80211: tests: add some scanning related tests wifi: mac80211: kunit: extend MFP tests wifi: mac80211: kunit: generalize public action test wifi: mac80211: add kunit tests for public action handling kunit: add a convenience allocation wrapper for SKBs kunit: add parameter generation macro using description from array wifi: mac80211: fix spelling typo in comment wifi: cfg80211: fix RCU dereference in __cfg80211_bss_update ==================== Link: https://lore.kernel.org/r/20240103144423.52269-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski

wifi: cfg80211: parse all ML elements in an ML probe response

2024-01-03T14:35:36Z

A probe response from a transmitting AP in an Multi-BSSID setup will contain more than one Multi-Link element. Most likely, only one of these elements contains per-STA profiles. Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses") Signed-off-by: Benjamin Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240102213313.6635eb152735.I94289002d4a2f7b6b44dfa428344854e37b0b29c@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: correct comment about MLD ID

2024-01-03T14:35:31Z

The comment was referencing the wrong section of the documentation and was also subtly wrong as it assumed the rules that apply when sending probe requests directly to a nontransmitted AP. However, in that case the response comes from the transmitting AP and the AP MLD ID will be included. Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses") Signed-off-by: Benjamin Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240102213313.0917ab4b5d7f.I76aff0e261a5de44ffb467e591a46597a30d7c0a@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: Update the default DSCP-to-UP mapping

2024-01-03T14:35:26Z

The default DSCP-to-UP mapping method defined in RFC8325 applied to packets marked per recommendations in RFC4594 and destined to 802.11 WLAN clients will yield a number of inconsistent QoS mappings. To handle this, modify the mapping of specific DSCP values for which the default mapping will create inconsistencies, based on the recommendations in section 4 in RFC8325. Note: RFC8235 is used as it referenced by both IEEE802.11Revme_D4.0 and WFA QoS Management Specification. Signed-off-by: Ilan Peer Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20231218093005.3064013-1-ilan.peer@intel.com Signed-off-by: Johannes Berg