Upstream has issued an advisory on September 11: https://w1.fi/security/2019-7/ap-mode-pmf-disconnection-protection-bypass.txt The advisory includes a patch to fix the issue, which will also be fixed in 2.10. Mageia 6 and Mageia 7 are also affected.
Whiteboard: (none) => MGA7TOO, MGA6TOO
Assigning to the 'wpa_supplicant' registered maintainer.
Assignee: bugsquad => tmb
CVE-2019-16275 has been assigned for this: https://www.openwall.com/lists/oss-security/2019/09/12/6
Summary: wpa_supplicant / hostapd new DoS security issue => wpa_supplicant / hostapd new DoS security issue (CVE-2019-16275)
Debian has issued an advisory for this on September 29: https://www.debian.org/security/2019/dsa-4538
Fedora has issued advisories for this on November 7 and 9: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/36G4XAZ644DMHBLKOL4FDSPZVIGNQY6U/ https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/FEGITWRTIWABW54ANEPCEF4ARZLXGSK5/
Whiteboard: MGA7TOO, MGA6TOO => MGA7TOO
Status comment: (none) => Fixed upstream in 2.10
fixed in cauldron
CC: (none) => mageiaVersion: Cauldron => 7Whiteboard: MGA7TOO => (none)
first part fixed in mga7 in the rpm wpa_supplicant-2.9-1.2.mga7
second part is if fixed in mga7 in hostapd-2.9-1.1.mga7
Assignee: tmb => qa-bugs
Advisory: ======================== Updated wpa_supplicant and hostpad packages fix security vulnerability: A vulnerability was discovered in wpa_supplicant. When Access Point (AP) mode and Protected Management Frames (PMF) (IEEE 802.11w) are enabled, wpa_supplicant does not perform enough validation on the source address of some received management frames. An attacker within the 802.11 communications range could use this flaw to inject an unauthenticated frame and perform a denial-of-service attack against another device which would be disconnected from the network (CVE-2019-16275). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16275 https://w1.fi/security/2019-7/ap-mode-pmf-disconnection-protection-bypass.txt https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/36G4XAZ644DMHBLKOL4FDSPZVIGNQY6U/ https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/FEGITWRTIWABW54ANEPCEF4ARZLXGSK5/
Status comment: Fixed upstream in 2.10 => (none)
Tried this on two separate 64-bit machines, connecting with my home network. Package installed cleanly. After update, I shut down my connection, checked the configuration, then reconnected to invoke the new wpa_supplicant. Then I did a cold boot, to check the connect-on-boot function. All was OK. Using one of those machines to write this report. OK for 64-bits. Validating. Advisory in Comment 8.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugsWhiteboard: (none) => MGA7-64-OK
Oops. Removing OK and validation. I forgot to try hostapd, and now that I did try it seems that my system isn't using it, so I can't test it. Someone else should do that before it can be OKed.
Keywords: validated_update => (none)Whiteboard: MGA7-64-OK => (none)
MGA7-64 Plasma on Lenovo B50 No installation issues. My wifi connection survived the installation, disconnecting and connecting again using both network center and networkmanager work OK. @ TJ hostapd is a problem # systemctl -l status hostapd ● hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator Loaded: loaded (/usr/lib/systemd/system/hostapd.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@mach5 ~]# systemctl start hostapd Job for hostapd.service failed because the control process exited with error code. See "systemctl status hostapd.service" and "journalctl -xe" for details. and from the journal: May 29 14:55:24 mach5.hviaene.thuis hostapd[9393]: Configuration file: /etc/hostapd/hostapd.conf May 29 14:55:24 mach5.hviaene.thuis hostapd[9393]: Could not read interface wlan0 flags: No such device My device is wlp9s0, so changed the /etc/hostapd/hostapd.conf for the line "interface", and then # systemctl start hostapd [root@mach5 ~]# systemctl -l status hostapd ● hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator Loaded: loaded (/usr/lib/systemd/system/hostapd.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2020-05-29 15:02:09 CEST; 14s ago Process: 6141 ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B (code=exited, status=0/SUCCES> Main PID: 6147 (hostapd) Tasks: 1 (limit: 4915) Memory: 840.0K CGroup: /system.slice/hostapd.service └─6147 /usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B May 29 15:02:09 mach5.hviaene.thuis systemd[1]: Starting Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authentic> May 29 15:02:09 mach5.hviaene.thuis hostapd[6141]: Configuration file: /etc/hostapd/hostapd.conf May 29 15:02:09 mach5.hviaene.thuis hostapd[6141]: Using interface wlp9s0 with hwaddr b4:6d:83:0d:0c:14 and ssid "test" May 29 15:02:09 mach5.hviaene.thuis hostapd[6141]: wlp9s0: interface state UNINITIALIZED->ENABLED May 29 15:02:09 mach5.hviaene.thuis hostapd[6141]: wlp9s0: AP-ENABLED May 29 15:02:09 mach5.hviaene.thuis systemd[1]: Started Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authentica> May 29 15:02:09 mach5.hviaene.thuis hostapd[6147]: wlp9s0: STA 34:31:c4:80:a9:b7 IEEE 802.11: disassociated That took the wifi connection down and immediately up again. Now I could do # hostapd_cli hostapd_cli v2.9 Copyright (c) 2004-2019, Jouni Malinen <j@w1.fi> and contributors This software may be distributed under the terms of the BSD license. See README for more details. Selected interface 'wlp9s0' Interactive mode > help commands: ping = pings hostapd mib = get MIB variables (dot1x, dot11, radius) relog = reload/truncate debug log output file status = show interface status info etc..... and > status state=ENABLED phy=phy0 freq=2412 num_sta_non_erp=0 num_sta_no_short_slot_time=0 num_sta_no_short_preamble=0 olbc=0 num_sta_ht_no_gf=0 num_sta_no_ht=0 num_sta_ht_20_mhz=0 num_sta_ht40_intolerant=0 olbc_ht=0 ht_op_mode=0x0 cac_time_seconds=0 cac_time_left_seconds=N/A channel=1 secondary_channel=0 ieee80211n=0 ieee80211ac=0 ieee80211ax=0 beacon_int=100 dtim_period=2 supported_rates=02 04 0b 16 0c 12 18 24 30 48 60 6c max_txpower=30 bss[0]=wlp9s0 bssid[0]=b4:6d:83:0d:0c:14 ssid[0]=test num_sta[0]=1 # systemctl stop hostapd That stopped, and took the wifi down, I had to start it again from MCC without problems. So, that seems reasonable. OK for me.
CC: (none) => herman.viaeneWhiteboard: (none) => MGA7-64-OK
Thanks, Herman. I didn't have a clue. Validating once more. Advisory still in Comment 8.
Keywords: (none) => validated_update
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0244.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED