A possible buffer overflow was discovered in wpa_supplicant-0.2.6, which is currently marked stable on x86, today: From: Jouni Malinen <jkmaline@cc.hut.fi> To: hostap@shmoo.com Subject: wpa_supplicant - new stable releases v0.3.8 and v0.2.7 Date: Sun, 13 Feb 2005 18:35:31 -0800 (Mon, 03:35 CET) New versions of wpa_supplicant stable branches were just released and are now available from http://hostap.epitest.fi/ This release is a bug fix release for all current stable branches. A missing validation of received EAPOL-Key frames was found during code review. This omission makes it possible to construct a packet that will cause wpa_supplicant to crash with segmentation fault due to buffer overflow when reading the invalid EAPOL-Key packet data. This omission of required validation step happened during addition of WPA2 support and is thus present in all released versions of wpa_supplicant except for the first v0.2.0 release that did not yet have WPA2 support. If WPA2 is enabled ('proto' configuration variable includes WPA2 or RSN, or is commented out in configuration), an unauthenticated EAPOL-Key frame (message 1 of 4-Way Handshake) can trigger this failure. If WPA2 is not enabled, only authenticated frames (message 3 of 4-Way Handshake) trigger this failure, i.e., AP must be able to determine the correct PMK and PTK to send such a frame. All users of wpa_supplicant are recommended to update to the new versions, either v0.3.8 or v0.2.7. Alternatively, the attached patch can be used to add the missing validation for EAPOL-Key frames. This patch should apply to all versions starting from v0.2.2 (with some offset differences). This change is also included in the current development snapshot. wpa_supplicant: * fixed EAPOL-Key validation to drop packets with invalid Key Data Length; such frames could have crashed wpa_supplicant due to buffer overflow
I have added net-wireless/wpa_supplicant-0.2.7 to portage and marked it stable on x86. I've also pulled all vulnerable versions of the package.
Thx Henrik. This one is ready for GLSA, Security please vote (or complain about B rating).
I vote YES, this can lead to denial of service in pure sense.
GLSA 200502-22 thanks everyone