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.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
