kernel/linux.git/net/mac80211/key.h, branch v7.1

wifi: mac80211: Use AES-CMAC library in ieee80211_aes_cmac()

2026-03-09T20:27:21+00:00

Now that AES-CMAC has a library API, convert the mac80211 AES-CMAC packet authentication code to use it instead of a "cmac(aes)" crypto_shash. This has multiple benefits, such as: - It's faster. The AES-CMAC code is now called directly, without unnecessary overhead such as indirect calls. - MAC calculation can no longer fail. - The AES-CMAC key struct is now a fixed size, allowing it to be embedded directly into 'struct ieee80211_key' rather than using a separate allocation. Note that although this increases the size of the 'u.cmac' field of 'struct ieee80211_key', it doesn't cause it to exceed the size of the largest variant of the union 'u'. Therefore, the size of 'struct ieee80211_key' itself is unchanged. Acked-by: Johannes Berg Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260218213501.136844-15-ebiggers@kernel.org Signed-off-by: Eric Biggers

wifi: mac80211: remove key_mtx

2023-09-11T09:27:22+00:00

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

wifi: mac80211: move key tailroom work to wiphy work

2023-09-11T09:27:20+00:00

This way we hold the wiphy mutex there, as a step towards removing some of the additional locks we have. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg

wifi: mac80211: implement link switching

2022-09-06T08:17:20+00:00

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

wifi: mac80211: properly implement MLO key handling

2022-08-25T08:41:07+00:00

Implement key installation and lookup (on TX and RX) for MLO, so we can use multiple GTKs/IGTKs/BIGTKs. Co-authored-by: Ilan Peer Signed-off-by: Ilan Peer Signed-off-by: Johannes Berg

wifi: mac80211: refactor some key code

2022-06-10T14:12:57+00:00

There's some pretty close code here, with the exception of RCU dereference vs. protected dereference. Refactor this to just return a pointer and then do the deref in the caller later. Change-Id: Ide5315e2792da6ac66eaf852293306a3ac71ced9 Signed-off-by: Johannes Berg

wifi: mac80211: remove cipher scheme support

2022-06-10T13:35:53+00:00

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

mac80211: prevent mixed key and fragment cache attacks

2021-05-11T18:12:51+00:00

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 Link: https://lore.kernel.org/r/20210511200110.3f8290e59823.I622a67769ed39257327a362cfc09c812320eb979@changeid Signed-off-by: Johannes Berg

mac80211: Support BIGTK configuration for Beacon protection

2020-02-24T09:35:57+00:00

Extend mac80211 key configuration to support the new BIGTK with key index values 6 and 7. Support for actually protecting Beacon frames (adding the MME in AP mode and checking it in STA mode) is covered in separate commits. Signed-off-by: Jouni Malinen Link: https://lore.kernel.org/r/20200222132548.20835-3-jouni@codeaurora.org Signed-off-by: Johannes Berg

mac80211: clear crypto tx tailroom counter upon keys enable

2019-09-11T07:33:28+00:00

In case we got a fw restart while roaming from encrypted AP to non-encrypted one, we might end up with hitting a warning on the pending counter crypto_tx_tailroom_pending_dec having a non-zero value. The following comment taken from net/mac80211/key.c explains the rational for the delayed tailroom needed: /* * The reason for the delayed tailroom needed decrementing is to * make roaming faster: during roaming, all keys are first deleted * and then new keys are installed. The first new key causes the * crypto_tx_tailroom_needed_cnt to go from 0 to 1, which invokes * the cost of synchronize_net() (which can be slow). Avoid this * by deferring the crypto_tx_tailroom_needed_cnt decrementing on * key removal for a while, so if we roam the value is larger than * zero and no 0->1 transition happens. * * The cost is that if the AP switching was from an AP with keys * to one without, we still allocate tailroom while it would no * longer be needed. However, in the typical (fast) roaming case * within an ESS this usually won't happen. */ The next flow lead to the warning eventually reported as a bug: 1. Disconnect from encrypted AP 2. Set crypto_tx_tailroom_pending_dec = 1 for the key 3. Schedule work 4. Reconnect to non-encrypted AP 5. Add a new key, setting the tailroom counter = 1 6. Got FW restart while pending counter is set ---> hit the warning While on it, the ieee80211_reset_crypto_tx_tailroom() func was merged into its single caller ieee80211_reenable_keys (previously called ieee80211_enable_keys). Also, we reset the crypto_tx_tailroom_pending_dec and remove the counters warning as we just reset both. Signed-off-by: Lior Cohen Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/20190830112451.21655-7-luca@coelho.fi Signed-off-by: Johannes Berg