On Fri, 2015-05-15 at 09:48 +0300, Emmanuel Grumbach wrote: > I'd be glad if someone could take a look. If not, I'll have someone > from our team to look at it, but I don't know how long it will take... Without looking too much - it seems to me that this is a fundamental problem with PTK rekeying, in that it re-uses the key index that is intended to avoid this. The issue at hand here is likely a hardware decryption vs. key replacing race, in that hardware decryption happens while the key replacing also happens, and then the PN checking after key replace hits the wrong key (due to the above-mentioned issue with not being able to change the key index in PTK rekeying.) I don't see how we can fix this, except perhaps heuristically by dropping packets that were encrypted with the *old* key and therefore not updating the replay counter for them. However, detecting that they were encrypted with the old key would only be possible by detecting a large jump in PN, which could theoretically also happen in real usage ... johannes -- 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
