We discovered a denial-of-service vulnerability that allows an adversary to forcibly disconnect the IWD client from a protected Wi-Fi network even when Wi-Fi Management Frame Protection (MFP) is being used. The problem is that the reception of an unprotected EAP-Failure message will cause the client to disconnect even when MFP is used, resulting in denial-of-service. Interestingly, the attack is successful against both personal and enterprise networks. In case of enterprise networks, the EAP-Failure ID has to match the session's randomized ID. However, since there are only 256 possible values, it can be quickly brute-forced. In case of personal networks, the EAP-Failure ID can be set to zero. Snippet from the logs: src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129) src/netdev.c:netdev_control_port_frame_event() EAP completed with eapFail 4-Way handshake failed for ifindex: 19, reason: 23 src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20) src/netdev.c:netdev_link_notify() event 16 on ifindex 19 src/netdev.c:netdev_mlme_notify() MLME notification Deauthenticate(39) src/netdev.c:netdev_deauthenticate_event() src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48) src/netdev.c:netdev_disconnect_event() We confirmed the attack against versions 1.24, 1.25, 1.26, 1.27. See the attachment for our proof-of-concept code to reproduce the issue. A potential solution is to discard EAP-Failure messages when the client is not using IEEE 802.1X authentication. Furthermore, one could choose to discard EAP-Failure messages after establishing a successful connection. This issue was discovered by Domien Schepers (Northeastern University) and Mathy Vanhoef (imec-DistriNet, KU Leuven).