hostapd before 2.10 and wpa_supplicant before 2.10 allow an incorrect indication of disconnection in certain situations because source address validation is mishandled. This is a denial of service that should have been prevented by PMF (aka management frame protection). The attacker must send a crafted 802.11 frame from a location that is within the 802.11 communications range.
Created hostapd tracking bugs for this issue:
Affects: epel-all [bug 1767028]
Affects: fedora-all [bug 1767027]
Created wpa_supplicant tracking bugs for this issue:
Affects: fedora-all [bug 1767026]
The flaw allows to bypass PMF, which should prevent disconnect attacks. Thus affected versions include those compiled with PMF support (CONFIG_IEEE80211W=y) and that have AP mode and PMF enabled at runtime. Moreover, the flaw can be triggered only when it is wpa_supplicant itself that controls the authentication and association management frames (e.g. drivers that use mac80211) and not when the driver directly handles those frames.
However when wpa_supplicant in AP mode is used, but PMF support is either not compiled in or not enabled at runtime, it is already possible for an attacker within the 802.11 communications range to perform a disconnect attack.
Functions ap/ieee802_11.c:ieee802_11_mgmt() and ap/drv_callbacks.c:hostapd_notif_assoc() were not correctly checking that the received frames actually contained an expected SA. By sending frames with an unexpected SA it is possible to make wpa_supplicant in AP mode to send response frames to another device and cause its disconnection.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):
This issue did not affect the versions of wpa_supplicant as shipped with Red Hat Enterprise Linux 5, 6, 7, and 8. Versions of the package shipped in Red Hat Enterprise Linux 5 and 6 are built without AP mode (CONFIG_AP=y), while versions of the package shipped in Red Hat Enterprise Linux 7 and 8, even though they support AP mode, do not enable IEEE 802.11w (CONFIG_IEEE80211W=y). Both options are required for the flaw to be exploited.