#
04577bfa |
| 28-Feb-2024 |
Shaul Triebitz <shaul.triebitz@intel.com> |
wifi: mac80211: add link id to ieee80211_gtk_rekey_add()
In MLO, we need the link id in the GTK key to be given by the driver after rekeying in wowlan, so add that.
Signed-off-by: Shaul Triebitz <s
wifi: mac80211: add link id to ieee80211_gtk_rekey_add()
In MLO, we need the link id in the GTK key to be given by the driver after rekeying in wowlan, so add that.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240228094500.ce1bfc83a680.I43a6f8ab2804ee07116a37d5b9ec601b843464b1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
3b220ed8 |
| 02-Jan-2024 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: add support for SPP A-MSDUs
If software crypto is used, simply add support for SPP A-MSDUs (and use it whenever enabled as required by the cfg80211 API).
If hardware crypto is used,
wifi: mac80211: add support for SPP A-MSDUs
If software crypto is used, simply add support for SPP A-MSDUs (and use it whenever enabled as required by the cfg80211 API).
If hardware crypto is used, leave it up to the driver to set the NL80211_EXT_FEATURE_SPP_AMSDU_SUPPORT flag and then check sta->spp_amsdu or the IEEE80211_KEY_FLAG_SPP_AMSDU key flag.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240102213313.b8ada4514e2b.I1ac25d5f158165b5a88062a5a5e4c4fbeecf9a5d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
e5dfb941 |
| 20-Oct-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: fix another key installation error path
Due to overlapping changes and merges, another error path ended up broken. Fix this one as well.
Reported-by: Jakub Kicinski <kuba@kernel.org
wifi: mac80211: fix another key installation error path
Due to overlapping changes and merges, another error path ended up broken. Fix this one as well.
Reported-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
d097ae01 |
| 19-Sep-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: fix potential key leak
When returning from ieee80211_key_link(), the key needs to have been freed or successfully installed. This was missed in a number of error paths, fix it.
Sign
wifi: mac80211: fix potential key leak
When returning from ieee80211_key_link(), the key needs to have been freed or successfully installed. This was missed in a number of error paths, fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
31db78a4 |
| 19-Sep-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: fix potential key use-after-free
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey
wifi: mac80211: fix potential key use-after-free
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add().
Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
463559b7 |
| 28-Aug-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: remove ampdu_mlme.mtx
We now hold the wiphy mutex everywhere that we use or needed the A-MPDU locking, so we don't need this mutex any more. Remove it.
Most of this change was done
wifi: mac80211: remove ampdu_mlme.mtx
We now hold the wiphy mutex everywhere that we use or needed the A-MPDU locking, so we don't need this mutex any more. Remove it.
Most of this change was done automatically with spatch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
2a8b665e |
| 28-Aug-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: remove key_mtx
We now hold the wiphy mutex everywhere that we use or needed the key_mtx, so we don't need this mutex any more. Remove it.
Most of this change was done automatically
wifi: mac80211: remove key_mtx
We now hold the wiphy mutex everywhere that we use or needed the key_mtx, so we don't need this mutex any more. Remove it.
Most of this change was done automatically with spatch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
4d3acf43 |
| 28-Aug-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: remove sta_mtx
We now hold the wiphy mutex everywhere that we use or needed the sta_mtx, so we don't need this mutex any more. Remove it.
Most of this change was done automatically
wifi: mac80211: remove sta_mtx
We now hold the wiphy mutex everywhere that we use or needed the sta_mtx, so we don't need this mutex any more. Remove it.
Most of this change was done automatically with spatch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
e3208fb7 |
| 28-Aug-2023 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: move key tailroom work to wiphy work
This way we hold the wiphy mutex there, as a step towards removing some of the additional locks we have.
Reviewed-by: Emmanuel Grumbach <emmanue
wifi: mac80211: move key tailroom work to wiphy work
This way we hold the wiphy mutex there, as a step towards removing some of the additional locks we have.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
8da1985f |
| 23-Aug-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
wifi: mac80211: Do not include crypto/algapi.h
The header file crypto/algapi.h is for internal use only. Use the header file crypto/utils.h instead.
Signed-off-by: Herbert Xu <herbert@gondor.apana
wifi: mac80211: Do not include crypto/algapi.h
The header file crypto/algapi.h is for internal use only. Use the header file crypto/utils.h instead.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Link: https://lore.kernel.org/r/E1qYlA0-006vFr-Ts@formenos.hmeau.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
f52a0b40 |
| 21-Jun-2023 |
Yedidya Benshimol <yedidya.ben.shimol@intel.com> |
wifi: mac80211: mark keys as uploaded when added by the driver
When the driver has some form of GTK rekeying offload, e.g. during WoWLAN, mac80211 can assume that keys that the driver adds for that
wifi: mac80211: mark keys as uploaded when added by the driver
When the driver has some form of GTK rekeying offload, e.g. during WoWLAN, mac80211 can assume that keys that the driver adds for that are already present in the hardware acceleration. Mark them accordingly.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230621144414.bc78c7ff2a3d.I5e313d69e2b6a7a4766ef82d0faa122dd4c1c46d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
3d901102 |
| 02-Sep-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: implement link switching
Implement an API function and debugfs file to switch active links.
Also provide an async version of the API so drivers can call it in arbitrary contexts, e.
wifi: mac80211: implement link switching
Implement an API function and debugfs file to switch active links.
Also provide an async version of the API so drivers can call it in arbitrary contexts, e.g. while in the authorized callback.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
efe9c2bf |
| 02-Sep-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: isolate driver from inactive links
In order to let the driver select active links and properly make multi-link connections, as a first step isolate the driver from inactive links, an
wifi: mac80211: isolate driver from inactive links
In order to let the driver select active links and properly make multi-link connections, as a first step isolate the driver from inactive links, and set the active links to be only the association link for client-side interfaces. For AP side nothing changes since APs always have to have all their links active.
To simplify things, update the for_each_sta_active_link() API to include the appropriate vif pointer.
This also implies not allocating a chanctx for an inactive link, which requires a few more changes.
Since we now no longer try to program multiple links to the driver, remove the check in the MLME code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
7c13844c |
| 27-Aug-2022 |
Sun Ke <sunke32@huawei.com> |
wifi: mac80211: fix potential deadlock in ieee80211_key_link()
Add the missing unlock before return in the error handling case.
Fixes: ccdde7c74ffd ("wifi: mac80211: properly implement MLO key hand
wifi: mac80211: fix potential deadlock in ieee80211_key_link()
Add the missing unlock before return in the error handling case.
Fixes: ccdde7c74ffd ("wifi: mac80211: properly implement MLO key handling") Signed-off-by: Sun Ke <sunke32@huawei.com> Link: https://lore.kernel.org/r/20220827022452.823381-1-sunke32@huawei.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
ccdde7c7 |
| 17-Aug-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: properly implement MLO key handling
Implement key installation and lookup (on TX and RX) for MLO, so we can use multiple GTKs/IGTKs/BIGTKs.
Co-authored-by: Ilan Peer <ilan.peer@inte
wifi: mac80211: properly implement MLO key handling
Implement key installation and lookup (on TX and RX) for MLO, so we can use multiple GTKs/IGTKs/BIGTKs.
Co-authored-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
bfd8403a |
| 16-May-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: reorg some iface data structs for MLD
Start reorganizing interface related data structures toward MLD. The most complex part here is for the keys, since we have to split the various
wifi: mac80211: reorg some iface data structs for MLD
Start reorganizing interface related data structures toward MLD. The most complex part here is for the keys, since we have to split the various kinds of GTKs off to the link but still need to use (for WEP) the other keys as a fallback even for multicast frames.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
92ea8df1 |
| 19-May-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: reject WEP or pairwise keys with key ID > 3
We don't really care too much right now since our data structures are set up to not have a problem with this, but clearly it's wrong to ac
wifi: mac80211: reject WEP or pairwise keys with key ID > 3
We don't really care too much right now since our data structures are set up to not have a problem with this, but clearly it's wrong to accept WEP and pairwise keys with key ID > 3.
However, with MLD we need to split into per-link (GTK, IGTK, BIGTK) and per interface/MLD (including WEP) keys so make sure this is not a problem.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
23a5f0af |
| 09-Feb-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: remove cipher scheme support
The only driver using this was iwlwifi, where we just removed the support because it was never really used. Remove the code from mac80211 as well.
Chang
wifi: mac80211: remove cipher scheme support
The only driver using this was iwlwifi, where we just removed the support because it was never really used. Remove the code from mac80211 as well.
Change-Id: I1667417a5932315ee9d81f5c233c56a354923f09 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
046d2e7c |
| 04-Apr-2022 |
Sriram R <quic_srirrama@quicinc.com> |
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee8
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it.
With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif.
To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this.
For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member.
For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info.
Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink.
@ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@
( s-> - var + deflink.var | si->sta. - var + deflink.var )
@sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@
( si-> - var + deflink.var )
Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
94034c40 |
| 11-May-2021 |
Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> |
mac80211: prevent mixed key and fragment cache attacks
Simultaneously prevent mixed key attacks (CVE-2020-24587) and fragment cache attacks (CVE-2020-24586). This is accomplished by assigning a uniq
mac80211: prevent mixed key and fragment cache attacks
Simultaneously prevent mixed key attacks (CVE-2020-24587) and fragment cache attacks (CVE-2020-24586). This is accomplished by assigning a unique color to every key (per interface) and using this to track which key was used to decrypt a fragment. When reassembling frames, it is now checked whether all fragments were decrypted using the same key.
To assure that fragment cache attacks are also prevented, the ID that is assigned to keys is unique even over (re)associations and (re)connects. This means fragments separated by a (re)association or (re)connect will not be reassembled. Because mac80211 now also prevents the reassembly of mixed encrypted and plaintext fragments, all cache attacks are prevented.
Cc: stable@vger.kernel.org Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> Link: https://lore.kernel.org/r/20210511200110.3f8290e59823.I622a67769ed39257327a362cfc09c812320eb979@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
a05829a7 |
| 22-Jan-2021 |
Johannes Berg <johannes.berg@intel.com> |
cfg80211: avoid holding the RTNL when calling the driver
Currently, _everything_ in cfg80211 holds the RTNL, and if you have a slow USB device (or a few) you can get some bad lock contention on that
cfg80211: avoid holding the RTNL when calling the driver
Currently, _everything_ in cfg80211 holds the RTNL, and if you have a slow USB device (or a few) you can get some bad lock contention on that.
Fix that by re-adding a mutex to each wiphy/rdev as we had at some point, so we have locking for the wireless_dev lists and all the other things in there, and also so that drivers still don't have to worry too much about it (they still won't get parallel calls for a single device).
Then, we can restrict the RTNL to a few cases where we add or remove interfaces and really need the added protection. Some of the global list management still also uses the RTNL, since we need to have it anyway for netdev management, but we only hold the RTNL for very short periods of time here.
Link: https://lore.kernel.org/r/20210122161942.81df9f5e047a.I4a8e1a60b18863ea8c5e6d3a0faeafb2d45b2f40@changeid Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> [marvell driver issues] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
4271d4bd |
| 29-Nov-2020 |
Johannes Berg <johannes.berg@intel.com> |
mac80211: support MIC error/replay detected counters driver update
Support the driver incrementing MIC error and replay detected counters when having detected a bad frame, if it drops it directly in
mac80211: support MIC error/replay detected counters driver update
Support the driver incrementing MIC error and replay detected counters when having detected a bad frame, if it drops it directly instead of relying on mac80211 to do the checks.
These are then exposed to userspace, though currently only in some cases and in debugfs.
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.20201129172929.fb59be9c6de8.Ife2260887366f585afadd78c983ebea93d2bb54b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
6aea26ce |
| 08-Sep-2020 |
Felix Fietkau <nbd@nbd.name> |
mac80211: rework tx encapsulation offload API
The current API (which lets the driver turn on/off per vif directly) has a number of limitations: - it does not deal with AP_VLAN - conditions for enabl
mac80211: rework tx encapsulation offload API
The current API (which lets the driver turn on/off per vif directly) has a number of limitations: - it does not deal with AP_VLAN - conditions for enabling (no tkip, no monitor) are only checked at add_interface time - no way to indicate 4-addr support
In order to address this, store offload flags in struct ieee80211_vif (easy to extend for decap offload later). mac80211 initially sets the enable flag, but gives the driver a chance to modify it before its settings are applied. In addition to the .add_interface op, a .update_vif_offload op is introduced, which can be used for runtime changes.
If a driver can't disable encap offload at runtime, or if it has some extra limitations, it can simply override the flags within those ops.
Support for encap offload with 4-address mode interfaces can be enabled by setting a flag from .add_interface or .update_vif_offload.
Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200908123702.88454-6-nbd@nbd.name [resolved conflict with commit aa2092a9bab3 ("ath11k: add raw mode and software crypto support")] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
453431a5 |
| 07-Aug-2020 |
Waiman Long <longman@redhat.com> |
mm, treewide: rename kzfree() to kfree_sensitive()
As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading.
In "kzalloc()", t
mm, treewide: rename kzfree() to kfree_sensitive()
As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading.
In "kzalloc()", the z is meaningful and an important part of what the caller wants.
In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or something. The "zero" part of the interface isn't even _relevant_.
The main reason that kzfree() exists is to clear sensitive information that should not be leaked to other future users of the same memory objects.
Rename kzfree() to kfree_sensitive() to follow the example of the recently added kvfree_sensitive() and make the intention of the API more explicit. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler.
The renaming is done by using the command sequence:
git grep -w --name-only kzfree |\ xargs sed -i 's/kzfree/kfree_sensitive/'
followed by some editing of the kfree_sensitive() kerneldoc and adding a kzfree backward compatibility macro in slab.h.
[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h] [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]
Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: David Howells <dhowells@redhat.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Joe Perches <joe@perches.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: David Rientjes <rientjes@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: "Jason A . Donenfeld" <Jason@zx2c4.com> Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
fc0561dc |
| 07-Jul-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
mac80211: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through mar
mac80211: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200707204548.GA9320@embeddedor Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|