starfive-tech/linux.git/net/wireless, branch JH7110_VisionFive2_multi_rtos

wifi: cfg80211: fix missing interfaces when dumping

2024-03-01T12:34:48+00:00

[ Upstream commit a6e4f85d3820d00694ed10f581f4c650445dbcda ] 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 Signed-off-by: Sasha Levin

wifi: cfg80211: fix wiphy delayed work queueing

2024-02-23T08:25:12+00:00

commit b743287d7a0007493f5cada34ed2085d475050b4 upstream. 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 Signed-off-by: Greg Kroah-Hartman

wifi: cfg80211: fix RCU dereference in __cfg80211_bss_update

2024-02-05T20:14:34+00:00

[ Upstream commit 1184950e341c11b6f82bc5b59564411d9537ab27 ] Replace rcu_dereference() with rcu_access_pointer() since we hold the lock here (and aren't in an RCU critical section). Fixes: 32af9a9e1069 ("wifi: cfg80211: free beacon_ies when overridden from hidden BSS") Reported-and-tested-by: syzbot+864a269c27ee06b58374@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://msgid.link/tencent_BF8F0DF0258C8DBF124CDDE4DD8D992DCF07@qq.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: cfg80211: free beacon_ies when overridden from hidden BSS

2024-02-05T20:14:24+00:00

[ Upstream commit 32af9a9e1069e55bc02741fb00ac9d0ca1a2eaef ] This is a more of a cosmetic fix. The branch will only be taken if proberesp_ies is set, which implies that beacon_ies is not set unless we are connected to an AP that just did a channel switch. And, in that case we should have found the BSS in the internal storage to begin with. Signed-off-by: Benjamin Berg Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20231220133549.b898e22dadff.Id8c4c10aedd176ef2e18a4cad747b299f150f9df@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

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

2024-01-25T23:35:30+00:00

[ Upstream commit d18125b640309e925441ce49559be33867ae6b29 ] 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 Signed-off-by: Sasha Levin

wifi: cfg80211: correct comment about MLD ID

2024-01-25T23:35:30+00:00

[ Upstream commit 2a0698f86d4dfc43cc0c1703efb7ba6b1506a4e2 ] 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 Signed-off-by: Sasha Levin

wifi: cfg80211: lock wiphy mutex for rfkill poll

2024-01-20T10:51:37+00:00

[ Upstream commit 8e2f6f2366219b3304b227bdd2f04b64c92e3e12 ] We want to guarantee the mutex is held for pretty much all operations, so ensure that here as well. Reported-by: syzbot+7e59a5bfc7a897247e18@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: nl80211: fix deadlock in nl80211_set_cqm_rssi (6.6.x)

2024-01-05T14:19:44+00:00

Commit 008afb9f3d57 ("wifi: cfg80211: fix CQM for non-range use" backported to 6.6.x) causes nl80211_set_cqm_rssi not to release the wdev lock in some of the error paths. Of course, the ensuing deadlock causes userland network managers to break pretty badly, and on typical systems this also causes lockups on on suspend, poweroff and reboot. See [1], [2], [3] for example reports. The upstream commit 7e7efdda6adb ("wifi: cfg80211: fix CQM for non-range use"), committed in November 2023, is completely fine because there was another commit in August 2023 that removed the wdev lock: see commit 076fc8775daf ("wifi: cfg80211: remove wdev mutex"). The reason things broke in 6.6.5 is that commit 4338058f6009 was applied without also applying 076fc8775daf. Commit 076fc8775daf ("wifi: cfg80211: remove wdev mutex") is a rather large commit; adjusting the error handling (which is what this commit does) yields a much simpler patch and was tested to work properly. Fix the deadlock by releasing the lock before returning. [1] https://bugzilla.kernel.org/show_bug.cgi?id=218247 [2] https://bbs.archlinux.org/viewtopic.php?id=290976 [3] https://lore.kernel.org/all/87sf4belmm.fsf@turtle.gmx.de/ Link: https://lore.kernel.org/stable/e374bb16-5b13-44cc-b11a-2f4eefb1ecf5@manjaro.org/ Fixes: 008afb9f3d57 ("wifi: cfg80211: fix CQM for non-range use") Tested-by: "Léo Lam" Tested-by: Philip Müller Cc: stable@vger.kernel.org Cc: Johannes Berg Signed-off-by: "Léo Lam" Signed-off-by: Greg Kroah-Hartman

wifi: cfg80211: fix CQM for non-range use

2024-01-05T14:19:44+00:00

commit 7e7efdda6adb385fbdfd6f819d76bc68c923c394 upstream. [note: this is commit 4a7e92551618f3737b305f62451353ee05662f57 reapplied; that commit had been reverted in 6.6.6 because it caused regressions, see https://lore.kernel.org/stable/2023121450-habitual-transpose-68a1@gregkh/ for details] My prior race fix here broke CQM when ranges aren't used, as the reporting worker now requires the cqm_config to be set in the wdev, but isn't set when there's no range configured. Rather than continuing to special-case the range version, set the cqm_config always and configure accordingly, also tracking if range was used or not to be able to clear the configuration appropriately with the same API, which was actually not right if both were implemented by a driver for some reason, as is the case with mac80211 (though there the implementations are equivalent so it doesn't matter.) Also, the original multiple-RSSI commit lost checking for the callback, so might have potentially crashed if a driver had neither implementation, and userspace tried to use it despite not being advertised as supported. Cc: stable@vger.kernel.org Fixes: 4a4b8169501b ("cfg80211: Accept multiple RSSI thresholds for CQM") Fixes: 37c20b2effe9 ("wifi: cfg80211: fix cqm_config access race") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman Signed-off-by: "Léo Lam" Signed-off-by: Greg Kroah-Hartman

wifi: cfg80211: fix certs build to not depend on file order

2024-01-01T12:42:39+00:00

commit 3c2a8ebe3fe66a5f77d4c164a0bea8e2ff37b455 upstream. The file for the new certificate (Chen-Yu Tsai's) didn't end with a comma, so depending on the file order in the build rule, we'd end up with invalid C when concatenating the (now two) certificates. Fix that. Cc: stable@vger.kernel.org Reported-by: Biju Das Reported-by: Naresh Kamboju Fixes: fb768d3b13ff ("wifi: cfg80211: Add my certificate") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman