Windows and iOS are apparently not vulnerable because - as per time-honoured tradition - they don't follow the 802.11 standard properly.
Not quite...
First of all the exploit has to get the client moved to its own channel (which looks like the target network but runs on a different channel). It does this by spoofing a channel change packet (which isn't encrypted) and the client dutifully follows this. The exploit can then forward the raw packets it receives to the real channel (where there will be replies) and can forward these replies to the hijacked client when they come in. It can do this even though the wifi frames are encrypted as it does not need to decrypt them or re-encrypt them on the way (indeed it can't as it does not know the encryption key).
The vulnerability then replays one of the encrypted wifi frames (the 3rd one in the 4 stage handshake) which tells the client to (re)install the encryption key. (Whether the protocol has protection against a replay attack like this I'm not sure, but since every client is vulnerable to this part I would guess not.)
The reason Linux and Android are subsequently and so easily vulnerable is because they are both based off Linux's wpa_supplicant which had zeroed out the memory holding the key after it first installed it (because the 802.11i spec suggested this as a security precaution so as not to leave the key in memory). The problem comes when it is told to (or rather tricked into) re-install the key it does exactly that - and so the encryption key it reinstalls is all zero bytes. This is how the exploit is able to decrypt subsequent packets straight away because it knows the encryption key that will be reinstalled. The exploit code then proxies the requests and responses so the client continues to receive its data.
Windows, iOS and other clients do reinstall the correct encryption key (because they didn't zero it out in memory) but they also reset the frame counters. This is a bad thing as it leads to nonce reuse which means the underlying ciphers (such as AES-GCM) are vulnerable to a birthday attack. Here the exploit has to gather lots of example encrypted data packets in order to derive the encryption key and start to passively decode the stream or actively inject packets. But the much easier fish to shoot in the barrel are the Linux/Android clients which simply move to a known encryption key when asked.
So the flaws are numerous, not least:-
* Clients can be moved from one channel to another by an unencrypted packet
* There's no encrypted confirmation done that the channel move request was legitimate
* Protocol allows original handshake frames to be replayed
* Clients are not warned to protect against replayed handshake frames
* Reinstalling the key requires keeping it in memory (against security best practices)
* Clients that tried to follow best practice (and zeroed out the key once installed) didn't fail when asked to reinstall the now zeroed key.
It's older Androids and all those Internet Of Shit devices that are going to be the main problem, as so many of them don't get updates.
As the old gag goes: The 'S' in 'IoT' stands for security.