Hi!
From: Mathy Vanhoef Mathy.Vanhoef@kuleuven.be
commit 94034c40ab4a3fcf581fbc7f8fdf4e29943c4a24 upstream.
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.
--- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -799,6 +799,7 @@ int ieee80211_key_link(struct ieee80211_ struct ieee80211_sub_if_data *sdata, struct sta_info *sta) {
- static atomic_t key_color = ATOMIC_INIT(0); struct ieee80211_key *old_key;
This is nice and simple, but does not include any kind of overflow handling. sparc32 moved away from 24-bit atomics, which is good I guess. OTOH if this is incremented 10 times a second, we'll still overflow in 6 years or so. Can attacker make it overflow?
Should this have a note why overflow is not possible / why it is not a problem?
Best regards, Pavel