summaryrefslogtreecommitdiffstats
path: root/net/mac80211
AgeCommit message (Collapse)AuthorFilesLines
2021-06-23mac80211: fix NULL ptr dereference during mesh peer connection for non HE ↵Abinaya Kalaiselvan1-1/+3
devices "sband->iftype_data" is not assigned with any value for non HE supported devices, which causes NULL pointer access during mesh peer connection in those devices. Fix this by accessing the pointer after HE capabilities condition check. Cc: stable@vger.kernel.org Fixes: 7f7aa94bcaf0 (mac80211: reduce peer HE MCS/NSS to own capabilities) Signed-off-by: Abinaya Kalaiselvan <akalaise@codeaurora.org> Link: https://lore.kernel.org/r/1624459244-4497-1-git-send-email-akalaise@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: Enable power save after receiving NULL packet ACKBassem Dawood1-4/+3
Trigger dynamic_ps_timer to re-evaluate power saving once a null function packet (with PM = 1) is ACKed, otherwise dynamic PS is not enabled at that point. Signed-off-by: Bassem Dawood <bassem@morsemicro.com> Link: https://lore.kernel.org/r/20210227055815.14838-1-bassem@morsemicro.com [reformatting] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: add HE 6 GHz capability only if supportedJohannes Berg1-4/+7
The HE 6 GHz capability should only be included if there are actually available channels on 6 GHz, and if that's the case we need to get it from the 6 GHz band data, not whatever other band we're on now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.290bf5c87030.I178aff1c3a6e32456d4ac9238e4a2eb47d209ccd@changeid Link: https://lore.kernel.org/r/iwlwifi.20210618133832.05e935e8dd98.I83ff7eb2ae8ebdf2e30c4fa2461344d9e569f599@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: notify driver on mgd TX completionJohannes Berg3-27/+103
We have mgd_prepare_tx(), but sometimes drivers may want/need to take action when the exchange finishes, whether successfully or not. Add a notification to the driver on completion, i.e. call the new method mgd_complete_tx(). To unify the two scenarios, and to add more information, make both of them take a struct that has the duration (prepare only), subtype (both) and success (complete only). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.5d94e78f6230.I6dc979606b6f28701b740d7aab725f7853a5a155@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: always include HE 6GHz capability in probe requestJohannes Berg1-1/+11
If HE/6GHz is available (thus we consider dot11HE6GOptionImplemented to be true), then always include the corresponding capability in the probe request as required by the spec. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.25ee4a54a7d0.I8cebd799c85524c8123a11941a104dbdefc03762@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: add vendor-specific capabilities to assoc requestJohannes Berg1-2/+10
When sending an association request, add any vendor specific capabilities at the end of the frame. This way, mac80211 is still completely in charge of building the frame, but drivers can determine what should be added depending on the band and interface type. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.80d716d69a5f.I28097ff19be6b22aebdc33a72795d2662755d41f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: conditionally advertise HE in probe requestsJohannes Berg1-1/+3
While building probe requests, only enable HE capability if there are actually any channels in the band with HE enabled, otherwise we're not really capable. We're doing the same in association requests, so doing it here makes it consistent. This also makes HE not appear available if it isn't due to regulatory constraints. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.b5513f2af335.Ic01862678712ae4238cea43ad2185928865efad2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: fix some spelling mistakesZheng Yongjun6-6/+6
Fix some spelling mistakes in comments: freeed ==> freed addreses ==> addresses containging ==> containing capablity ==> capability sucess ==> success atleast ==> at least Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20210607150047.2855962-1-zhengyongjun3@huawei.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: remove use of ieee80211_get_he_sta_cap()Johannes Berg4-13/+29
All uses of ieee80211_get_he_sta_cap() were actually wrong, in net/mac80211/mlme.c they were wrong because that code is also used for P2P (which is a different interface type), in net/mac80211/main.c that should check all interface types. Fix all that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.ede114bc8b46.Ibcd9a5d98430e936344eb6d242ef8a65c2f59b74@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: improve AP disconnect messageJohannes Berg1-2/+2
If the AP changes capability/bandwidth in some fashion, the message might be somewhat misleading and we don't know what really changed. Modify the message to speak about "caps/bw" instead of just "bandwidth", and print out the flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.dc22c48985fa.I4bf5fbc17ec783c21d4b50c8c35b1de390896ccd@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: rearrange struct txq_info for fewer holesJohannes Berg1-3/+6
We can slightly decrease the size of struct txq_info by rearranging some fields for fewer holes, so do that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.1bf019a1fe2e.Ib54622b8d6dc1a9a7dc484e573c073119450538b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: Properly WARN on HW scan before restartIlan Peer1-4/+3
The following race was possible: 1. The device driver requests HW restart. 2. A scan is requested from user space and is propagated to the driver. During this flow HW_SCANNING flag is set. 3. The thread that handles the HW restart is scheduled, and before starting the actual reconfiguration it checks that HW_SCANNING is not set. The flow does so without acquiring any lock, and thus the WARN fires. Fix this by checking that HW_SCANNING is on only after RTNL is acquired, i.e., user space scan request handling is no longer in transit. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.8238ab3e19ab.I2693c581c70251472b4f9089e37e06fb2c18268f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: add to bss_conf if broadcast TWT is supportedShaul Triebitz1-0/+18
Add to struct ieee80211_bss_conf a twt_broadcast field. Set it to true if both STA and AP support broadcast TWT. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.f7c105237541.I50b302044e2b35e5ed4d3fb8bc7bd3d8bb89b1e1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: handle rate control (RC) racing with chanctx definitionMordechay Goodstein2-126/+71
chanctx represents the current phy configuration and rate scale uses it for achieving max throughput, so if phy changes bandwidth to narrow bandwidth, RC should be _first_ updated to avoid using the wider bandwidth before updating the phy, and vice versa. We assume in the patch that station interface is always updated before updating phy context by calling ieee80211_vif_update_chandef. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.fc4e24496aa2.Ic40ea947c2f65739ea4b5fe3babd0a544240ced6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: free skb in WEP error caseJohannes Berg1-1/+4
If, for some strange reason, ieee80211_wep_encrypt() fails in ieee80211_send_auth() free the SKB instead of sending out the useless frame, in addition to the warning. This can't really happen since the SKB was freshly allocated. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.98f058d7a8b2.Ie605e6a10e72eae02f5734032826af48b85b6d11@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: move SMPS mode setting after ieee80211_prep_connectionShaul Triebitz1-9/+9
ieee80211_mgd_assoc calls ieee80211_prep_connection which might call ieee80211_prep_channel and set smps_mode to OFF. That will override the previous setting of smps_mode in ieee80211_mgd_assoc and HT SMPS will be set to "disabled" in the association request frame. Move the setting of smps_mode in ieee80211_mgd_assoc to after the call to ieee80211_prep_connection. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.d8e5cc4b527f.Icf3a67fffbdd8c408c0cadfe43f8f4cffdc90acb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: allow SMPS requests only in client modeJohannes Berg1-10/+8
The code currently allows this for AP mode, but then ignores it. Clarify that since the spec doesn't allow it in AP mode. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.0465f8bcbe32.Iba39fc559ecfa887be00a5f3beabd881e5c86e54@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: remove iwlwifi specific workaround that broke sta NDP txFelix Fietkau1-9/+0
Sending nulldata packets is important for sw AP link probing and detecting 4-address mode links. The checks that dropped these packets were apparently added to work around an iwlwifi firmware bug with multi-TID aggregation. Fixes: 41cbb0f5a295 ("mac80211: add support for HE") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210619101517.90806-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: check per vif offload_flags in Tx pathRyder Lee1-0/+3
offload_flags has been introduced to indicate encap status of each interface. An interface can encap offload at runtime, or if it has some extra limitations it can simply override the flags, so it's more flexible to check offload_flags in Tx path. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://lore.kernel.org/r/177785418cf407808bf3a44760302d0647076990.1623961575.git.ryder.lee@mediatek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: add rate control support for encap offloadRyder Lee2-6/+15
The software rate control cannot deal with encap offload, so fix it. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://lore.kernel.org/r/20210617163113.75815-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: call ieee80211_tx_h_rate_ctrl() when dequeueRyder Lee1-23/+29
Make ieee80211_tx_h_rate_ctrl() get called on dequeue to improve performance since it reduces the turnaround time for rate control. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://lore.kernel.org/r/20210617163113.75815-2-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: move A-MPDU session check from minstrel_ht to mac80211Felix Fietkau2-27/+28
This avoids calling back into tx handlers from within the rate control module. Preparation for deferring rate control until tx dequeue Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210617163113.75815-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: don't open-code LED manipulationsJohannes Berg1-10/+2
We shouldn't open-code led_trigger_blink() or led_trigger_event(), use them instead of badly open-coding them. This also fixes the locking, led_trigger_blink() and led_trigger_event() now use read_lock_irqsave(). Link: https://lore.kernel.org/r/20210616212804.b19ba1c60353.I8ea1b4defd5e12fc20ef281291e602feeec336a6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: consider per-CPU statistics if presentJohannes Berg1-8/+3
If we have been keeping per-CPU statistics, consider them regardless of USES_RSS, because we may not actually fill those, for example in non-fast-RX cases when the connection is not compatible with fast-RX. If we didn't fill them, the additional data will be zero and not affect anything, and if we did fill them then it's more correct to consider them. This fixes an issue in mesh mode where some statistics are not updated due to USES_RSS being set, but fast-RX isn't used. Reported-by: Thiraviyam Mariyappan <tmariyap@codeaurora.org> Link: https://lore.kernel.org/r/20210610220814.13b35f5797c5.I511e9b33c5694e0d6cef4b6ae755c873d7c22124@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: remove the repeated declarationShaokun Zhang1-1/+0
Function 'ieee80211_sta_set_rx_nss' is declared twice, so remove the repeated declaration. Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Link: https://lore.kernel.org/r/1622196424-62403-1-git-send-email-zhangshaokun@hisilicon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: refactor rc_no_data_or_no_ack_use_min functionPhilipp Borgers1-5/+1
Use newly introduced helper function ieee80211_is_tx_data to check if frame is a data frame. Takes into account that hardware encapsulation can be enabled for a frame and therefore no ieee80211 header is present. Signed-off-by: Philipp Borgers <borgers@mi.fu-berlin.de> Link: https://lore.kernel.org/r/20210519122019.92359-4-borgers@mi.fu-berlin.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: do not use low data rates for data frames with no ack flagPhilipp Borgers1-0/+4
Data Frames with no ack flag set should be handled by the rate controler. Make sure we reach the rate controler by returning early from rate_control_send_low if the frame is a data frame with no ack flag. Signed-off-by: Philipp Borgers <borgers@mi.fu-berlin.de> Link: https://lore.kernel.org/r/20210519122019.92359-3-borgers@mi.fu-berlin.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: simplify ieee80211_add_station()Johannes Berg1-9/+1
There's no need to do some kind of weird err and RCU dance just use sta_info_insert() directly. Link: https://lore.kernel.org/r/20210517230754.55abd10056c0.I6f5a3b7b23347b2cdaf64e6d5ce1d9e904059654@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: use sdata->skb_queue for TDLSJohannes Berg5-46/+23
We need to differentiate these frames since the ones we currently put on the skb_queue_tdls_chsw have already been converted to ethernet format, but now that we've got a single place to enqueue to the sdata->skb_queue this isn't hard. Just differentiate based on protocol and adjust the code to queue the SKBs appropriately. Link: https://lore.kernel.org/r/20210517230754.17034990abef.I5342f2183c0d246b18d36c511eb3b6be298a6572@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: refactor SKB queue processing a bitJohannes Berg1-109/+119
This is a very long loop body, move it into its own function instead, keeping only the kcov and free outside in the loop body. Link: https://lore.kernel.org/r/20210517230754.6bc6cdd68570.I28a86ebdb19601ca1965c4dc654cc49fc1064efa@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: unify queueing SKB to ifaceJohannes Berg1-18/+15
We have a bunch of places that open-code the same to queue an SKB to an interface, unify that. Link: https://lore.kernel.org/r/20210517230754.113b65febd5a.Ie0e1d58a2885e75f242cb6e06f3b9660117fef93@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: minstrel_ht: ignore frame that was sent with noAck flagPhilipp Borgers1-0/+4
QoS Data Frames that were sent with a No Ack policy should be ignored by the minstrel statistics. There will never be an Ack for these frames so there is no way to draw conclusions about the success of the transmission. Signed-off-by: Philipp Borgers <borgers@mi.fu-berlin.de> Link: https://lore.kernel.org/r/20210517120145.132814-1-borgers@mi.fu-berlin.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-23mac80211: Remove redundant assignment to retYang Li1-1/+0
Variable 'ret' is set to -ENODEV but this value is never read as it is overwritten with a new value later on, hence it is a redundant assignment and can be removed. Clean up the following clang-analyzer warning: net/mac80211/debugfs_netdev.c:60:2: warning: Value stored to 'ret' is never read [clang-analyzer-deadcode.DeadStores] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/1619774483-116805-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-18mac80211: handle various extensible elements correctlyJohannes Berg1-11/+11
Various elements are parsed with a requirement to have an exact size, when really we should only check that they have the minimum size that we need. Check only that and therefore ignore any additional data that they might carry. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.cd101f8040a4.Iadf0e9b37b100c6c6e79c7b298cc657c2be9151a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-18mac80211: reset profile_periodicity/ema_apJohannes Berg1-0/+8
Apparently we never clear these values, so they'll remain set since the setting of them is conditional. Clear the values in the relevant other cases. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.316e32d136a9.I2a12e51814258e1e1b526103894f4b9f19a91c8d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-18mac80211: minstrel_ht: fix sample time checkFelix Fietkau1-1/+1
We need to skip sampling if the next sample time is after jiffies, not before. This patch fixes an issue where in some cases only very little sampling (or none at all) is performed, leading to really bad data rates Fixes: 80d55154b2f8 ("mac80211: minstrel_ht: significantly redesign the rate probing strategy") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210617103854.61875-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-09mac80211: drop multicast fragmentsJohannes Berg1-6/+3
These are not permitted by the spec, just drop them. Link: https://lore.kernel.org/r/20210609161305.23def022b750.Ibd6dd3cdce573dae262fcdc47f8ac52b883a9c50@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-09mac80211: move interface shutdown out of wiphy lockJohannes Berg3-4/+12
When reconfiguration fails, we shut down everything, but we cannot call cfg80211_shutdown_all_interfaces() with the wiphy mutex held. Since cfg80211 now calls it on resume errors, we only need to do likewise for where we call reconfig (whether directly or indirectly), but not under the wiphy lock. Cc: stable@vger.kernel.org Fixes: 2fe8ef106238 ("cfg80211: change netdev registration/unregistration semantics") Link: https://lore.kernel.org/r/20210608113226.78233c80f548.Iecc104aceb89f0568f50e9670a9cb191a1c8887b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-09mac80211: fix 'reset' debugfs lockingJohannes Berg1-1/+3
cfg80211 now calls suspend/resume with the wiphy lock held, and while there's a problem with that needing to be fixed, we should do the same in debugfs. Cc: stable@vger.kernel.org Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") Link: https://lore.kernel.org/r/20210608113226.14020430e449.I78e19db0a55a8295a376e15ac4cf77dbb4c6fb51@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-06-08mac80211: fix deadlock in AP/VLAN handlingJohannes Berg1-7/+12
Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there. To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can't easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn't used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case Cc: stable@vger.kernel.org Reported-by: syzbot+452ea4fbbef700ff0a56@syzkaller.appspotmail.com Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") Link: https://lore.kernel.org/r/20210517160322.9b8f356c0222.I392cb0e2fa5a1a94cf2e637555d702c7e512c1ff@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-31mac80211: Fix NULL ptr deref for injected rate infoMathy Vanhoef1-16/+36
The commit cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue") moved the code to validate the radiotap header from ieee80211_monitor_start_xmit to ieee80211_parse_tx_radiotap. This made is possible to share more code with the new Tx queue selection code for injected frames. But at the same time, it now required the call of ieee80211_parse_tx_radiotap at the beginning of functions which wanted to handle the radiotap header. And this broke the rate parser for radiotap header parser. The radiotap parser for rates is operating most of the time only on the data in the actual radiotap header. But for the 802.11a/b/g rates, it must also know the selected band from the chandef information. But this information is only written to the ieee80211_tx_info at the end of the ieee80211_monitor_start_xmit - long after ieee80211_parse_tx_radiotap was already called. The info->band information was therefore always 0 (NL80211_BAND_2GHZ) when the parser code tried to access it. For a 5GHz only device, injecting a frame with 802.11a rates would cause a NULL pointer dereference because local->hw.wiphy->bands[NL80211_BAND_2GHZ] would most likely have been NULL when the radiotap parser searched for the correct rate index of the driver. Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Fixes: cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue") Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> [sven@narfation.org: added commit message] Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://lore.kernel.org/r/20210530133226.40587-1-sven@narfation.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-31mac80211: fix skb length check in ieee80211_scan_rx()Du Cheng1-5/+16
Replace hard-coded compile-time constants for header length check with dynamic determination based on the frame type. Otherwise, we hit a validation WARN_ON in cfg80211 later. Fixes: cd418ba63f0c ("mac80211: convert S1G beacon to scan results") Reported-by: syzbot+405843667e93b9790fc1@syzkaller.appspotmail.com Signed-off-by: Du Cheng <ducheng2@gmail.com> Link: https://lore.kernel.org/r/20210510041649.589754-1-ducheng2@gmail.com [style fixes, reword commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-31mac80211: remove warning in ieee80211_get_sband()Johannes Berg1-1/+1
Syzbot reports that it's possible to hit this from userspace, by trying to add a station before any other connection setup has been done. Instead of trying to catch this in some other way simply remove the warning, that will appropriately reject the call from userspace. Reported-by: syzbot+7716dbc401d9a437890d@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20210517164715.f537da276d17.Id05f40ec8761d6a8cc2df87f1aa09c651988a586@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-11mac80211: extend protection against mixed key and fragment cache attacksWen Gong1-2/+11
For some chips/drivers, e.g., QCA6174 with ath10k, the decryption is done by the hardware, and the Protected bit in the Frame Control field is cleared in the lower level driver before the frame is passed to mac80211. In such cases, the condition for ieee80211_has_protected() is not met in ieee80211_rx_h_defragment() of mac80211 and the new security validation steps are not executed. Extend mac80211 to cover the case where the Protected bit has been cleared, but the frame is indicated as having been decrypted by the hardware. This extends protection against mixed key and fragment cache attack for additional drivers/chips. This fixes CVE-2020-24586 and CVE-2020-24587 for such cases. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1 Cc: stable@vger.kernel.org Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Link: https://lore.kernel.org/r/20210511200110.037aa5ca0390.I7bb888e2965a0db02a67075fcb5deb50eb7408aa@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-11mac80211: do not accept/forward invalid EAPOL framesJohannes Berg1-6/+27
EAPOL frames are used for authentication and key management between the AP and each individual STA associated in the BSS. Those frames are not supposed to be sent by one associated STA to another associated STA (either unicast for broadcast/multicast). Similarly, in 802.11 they're supposed to be sent to the authenticator (AP) address. Since it is possible for unexpected EAPOL frames to result in misbehavior in supplicant implementations, it is better for the AP to not allow such cases to be forwarded to other clients either directly, or indirectly if the AP interface is part of a bridge. Accept EAPOL (control port) frames only if they're transmitted to the own address, or, due to interoperability concerns, to the PAE group address. Disable forwarding of EAPOL (or well, the configured control port protocol) frames back to wireless medium in all cases. Previously, these frames were accepted from fully authenticated and authorized stations and also from unauthenticated stations for one of the cases. Additionally, to avoid forwarding by the bridge, rewrite the PAE group address case to the local MAC address. Cc: stable@vger.kernel.org Co-developed-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Link: https://lore.kernel.org/r/20210511200110.cb327ed0cabe.Ib7dcffa2a31f0913d660de65ba3c8aca75b1d10f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-11mac80211: prevent attacks on TKIP/WEP as wellJohannes Berg2-1/+14
Similar to the issues fixed in previous patches, TKIP and WEP should be protected even if for TKIP we have the Michael MIC protecting it, and WEP is broken anyway. However, this also somewhat protects potential other algorithms that drivers might implement. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.430e8c202313.Ia37e4e5b6b3eaab1a5ae050e015f6c92859dbe27@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-11mac80211: check defrag PN against current frameJohannes Berg3-9/+20
As pointed out by Mathy Vanhoef, we implement the RX PN check on fragmented frames incorrectly - we check against the last received PN prior to the new frame, rather than to the one in this frame itself. Prior patches addressed the security issue here, but in order to be able to reason better about the code, fix it to really compare against the current frame's PN, not the last stored one. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.bfbc340ff071.Id0b690e581da7d03d76df90bb0e3fd55930bc8a0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-11mac80211: add fragment cache to sta_infoJohannes Berg5-43/+73
Prior patches protected against fragmentation cache attacks by coloring keys, but this shows that it can lead to issues when multiple stations use the same sequence number. Add a fragment cache to struct sta_info (in addition to the one in the interface) to separate fragments for different stations properly. This then automatically clear most of the fragment cache when a station disconnects (or reassociates) from an AP, or when client interfaces disconnect from the network, etc. On the way, also fix the comment there since this brings us in line with the recommendation in 802.11-2016 ("An AP should support ..."). Additionally, remove a useless condition (since there's no problem purging an already empty list). Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.fc35046b0d52.I1ef101e3784d13e8f6600d83de7ec9a3a45bcd52@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-11mac80211: drop A-MSDUs on old ciphersJohannes Berg1-1/+18
With old ciphers (WEP and TKIP) we shouldn't be using A-MSDUs since A-MSDUs are only supported if we know that they are, and the only practical way for that is HT support which doesn't support old ciphers. However, we would normally accept them anyway. Since we check the MMIC before deaggregating A-MSDUs, and the A-MSDU bit in the QoS header is not protected in TKIP (or WEP), this enables attacks similar to CVE-2020-24588. To prevent that, drop A-MSDUs completely with old ciphers. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210511200110.076543300172.I548e6e71f1ee9cad4b9a37bf212ae7db723587aa@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2021-05-11mac80211: properly handle A-MSDUs that start with an RFC 1042 headerMathy Vanhoef1-1/+1
Properly parse A-MSDUs whose first 6 bytes happen to equal a rfc1042 header. This can occur in practice when the destination MAC address equals AA:AA:03:00:00:00. More importantly, this simplifies the next patch to mitigate A-MSDU injection attacks. Cc: stable@vger.kernel.org Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> Link: https://lore.kernel.org/r/20210511200110.0b2b886492f0.I23dd5d685fe16d3b0ec8106e8f01b59f499dffed@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-10 02:50:23 +0000