The IEEE 802.11 standard sometimes enables an adversary to trick a victim into connecting to an unintended or untrusted network with Home WEP, Home WPA3 SAE-loop. Enterprise 802.1X/EAP, Mesh AMPE, or FILS, aka an "SSID Confusion" issue. This occurs because the SSID is not always used to derive the pairwise master key or session keys, and because there is not a protected exchange of an SSID during a 4-way handshake. References: https://mentor.ieee.org/802.11/dcn/24/11-24-0938-03-000m-protect-ssid-in-4-way-handshake.docx https://www.top10vpn.com/assets/2024/05/Top10VPN-x-Vanhoef-SSID-Confusion.pdf https://www.top10vpn.com/research/wifi-vulnerability-ssid/ https://www.wi-fi.org/news-events/press-releases
public at following link, remove embargo: https://www.top10vpn.com/research/wifi-vulnerability-ssid/
Created NetworkManager tracking bugs for this issue: Affects: fedora-all [bug 2293094] Created hostapd tracking bugs for this issue: Affects: epel-all [bug 2293096] Affects: fedora-all [bug 2293097] Created linux-firmware tracking bugs for this issue: Affects: fedora-all [bug 2293098] Created wpa_supplicant tracking bugs for this issue: Affects: fedora-all [bug 2293095]
(In reply to Anten Skrabec from comment #2) > public at following link, remove embargo: > https://www.top10vpn.com/research/wifi-vulnerability-ssid/ Looking at this I would expect this to cover the linux kernel plus userspace. What wireless firmware are affected by this? Also suspect you've missed iwd (similar to wpa_supplicant).
Created iwd tracking bugs for this issue: Affects: fedora-all [bug 2294016]
> Created linux-firmware tracking bugs After reading the documentation on the CVE, the fix is likely to not be in wifi *firmware*, but in software (prefer / force WPA3 SAE-const mode instead of SAE-loop): IIRC these days authentication protocols are not delegated to firmware, as they evolve too quickly, and may need some CPU power to do elliptic curve math and such, thus host CPU is much more suitable location to handle it.