Re: [PATCH 2/3] mac80211: revamp key handling

[Michael Buesch <mb@bu3sch.de>]

On Friday 31 August 2007, Johannes Berg wrote:
> Huh, this turned out to be buggy in b43:
> 
> > @@ -2921,13 +2919,15 @@ static int b43_dev_set_key(struct ieee80
> >  			err = b43_key_write(dev, index, algorithm,
> >  					    key->key, key->keylen, NULL, key);
> >  		} else {
> > +			/*
> > +			 * either pairwise key or address is 00:00:00:00:00:00
> > +			 * for transmit-only keys
> > +			 */
> >  			err = b43_key_write(dev, -1, algorithm,
> >  					    key->key, key->keylen, addr, key);
> >  		}
> > -		if (err) {
> > -			key->flags |= IEEE80211_KEY_FORCE_SW_ENCRYPT;
> > +		if (err)
> >  			goto out_unlock;
> > -		}
> >  		dev->key[key->hw_key_idx].enabled = 1;
> >  
> >  		if (algorithm == B43_SEC_ALGO_WEP40 ||
> 
> The same obviously has to be done when deleting keys. Michael, you can
> either use the patch below or rework it to use the hw_key_idx to delete
> the key.
> 
> Interestingly, this way I found out that when the B43_RX_MAC_DECERR flag
> is set on a frame, then the hardware has decrypted the data with the
> wrong key and then found that the ICV isn't correct so that the data is
> completely mangled. Hence, you should simply drop the frame in that case
> instead of passing it up, mac80211 will simply again attempt to decrypt
> it and, since the frame is already decrypted with the wrong key, only
> get garbage. This could even be used to DoS a machine with little
> resources like an AP: simply send a lot of broken frames that mac80211
> will try to decrypt in software.

I am sorry. I introduced this as I didn't understand my own weird code anymore. :)
I think I'll fix this by using the hw_key_idx.