Google has issued an advisory on February 1: https://source.android.com/security/bulletin/2021-02-01 As mentioned here, one issue is in wpa_supplicant / hostapd: https://lists.infradead.org/pipermail/hostap/2021-February/039294.html The patch is linked from the message above. Mageia 7 is also affected.
Status comment: (none) => Patch available from AndroidWhiteboard: (none) => MGA7TOO
Parentless SRPMs, have to assign this bug globally.
Assignee: bugsquad => pkg-bugs
fixed in cauldron.
Version: Cauldron => 7CC: (none) => mageiaWhiteboard: MGA7TOO => (none)
fixes pushed in mga7 too
Assignee: pkg-bugs => qa-bugs
I see you fixed the patch in wpa_supplicant but hostapd still has a reference to android.
Version: 7 => CauldronAssignee: qa-bugs => mageiaStatus comment: Patch available from Android => (none)
Upstream has posted an advisory for this on February 4: https://w1.fi/security/2020-2/wpa_supplicant-p2p-group-info-processing-vulnerability.txt hostapd is not affected (and I've corrected the patch in SVN anyway). Files list for Mageia 7 update: wpa_supplicant-2.9-1.3.mga7 wpa_supplicant-gui-2.9-1.3.mga7 from wpa_supplicant-2.9-1.3.mga7.src.rpm
Source RPM: hostapd-2.9-3.mga8.src.rpm, wpa_supplicant-2.9-7.mga8.src.rpm => wpa_supplicant-2.9-1.2.mga7.src.rpmAssignee: mageia => qa-bugsVersion: Cauldron => 7Summary: wpa_supplicant, hostapd new security issue CVE-2021-0326 => wpa_supplicant new security issue CVE-2021-0326
I have a question about this one. In my experience, a wpa_supplicant update comes with a choice of whether to use an rpmnew or do nothing, or, um, I forget. Choosing to do nothing keeps all your wifi configurations, while choosing rpmnew causes them to need to be redone. In this particular update, for testing purposes, is it more important to choose one option over the other?
CC: (none) => andrewsfarm
No config file changes have been made in the package, so you can keep your existing config. The update also only affects P2P (adhoc mode maybe?)
Thanks for getting back to me. The only P2P stuff I do is with ktorrent, so I guess I'll give that a try with the RC for lack of anything else. I have an appointment to take care of first, but I'll git 'er done and report back.
Tested on a 64-bit Plasma system on a desktop with an i5-2500, 16GB RAM, Intel graphics. Normally, this system is connected using Ethernet, but for this test I used a Ralink-based usb device. No installation issues. No issues with connecting the wifi device to my network after disconnecting the wired connection. No issues with Firefox, maneuvering to get the magnet link to use Ktorrent to get the 64-bit RC CI. But, shortly after starting the torrent, thirty seconds or less, I noticed that the cursor wasn't responding to movements or clicks of my Logitech cordless mouse. Ktorrent was fine - it was just the cursor. I was able to shut down ktorrent with a ctrl-Q from the keyboard (same receiver as the mouse!) About a second after that shut down, mouse action returned to normal. When I brought ktorrent back up again, the cursor became unresponsive as the download speed ramped up. Shut it down again, and it returned to normal. Thinking it was acting like the cpu was busy, I ran ksysguard to monitor it, and ran ktorrent again. Ksysguard showed nothing abnormal that I noticed. In the end, I disconnected from the wifi and used the wired connection again - and all was normal once more, even when ktorrent was running. Ran the wifi again and just used Firefox, and all is OK. Using it now to file this report. Starting to wonder... Did anybody actually try this in Cauldron with a Bittorrent client?
The usb device in the above comment is the Ralink MT7601U. I tried switching devices to a Realtec rtl8192cu. That was actually better. Cursor movement was there, but very jerky. The higher the download speed, the jerkier it was. In ksysguard I do see brief flashes of intense cpu activity when using the wifi. Interestingly enough, though, the cpu is MUCH more active when using the wired connection. But that is as would be expected, because the wired connection was downloading at 4 or 5 times the speed of the wifi. Hmmm. Maybe that is the problem - ktorrent is overloading the wifi device, trying to move data quicker than it can handle, and that, in turn, affects the cordless mouse.The usb port is usb 2.0, and can only transmit data so fast. Yes, that makes sense - the mouse receiver is usb as well.
I tried this in another machine, this one with a PCI-e wifi card, rather than usb. This was on a 32-bit Plasma system, AMD Phenom II X4, with an Atheros-based wifi and the same model Logitech cordless mouse/keyboard. This one worked MUCH better. I was able to achieve download speeds more than twice as fast as with either of the usb devices, yet mouse/cursor movement was unaffected at all but the very highest speed - and even then I only noticed it because I was looking for it. So it would seem that my earlier problem was coming from just trying to exceed the capabilities of my hardware. Changing the settings in ktorrent to limit download speed would probably avoid the problem. Calling this OK for both arches, and validating.
Whiteboard: (none) => MGA7-32-OK MGA7-64-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
I see you got some misunderstanding here... Wifi P2P is not same p2p as torrents & co For wifi it's about Wifi Direct, meaning allowing devices with the appropriate hardware to connect directly to each other via Wi-Fi without the help of an access point...
tj, I suspect you'll find it's hanging due to device waits, not cpu usage. To confirm, install htop, run it press f6 and select STATE as the sort by column (S in the column headers). You'll see processes stuck with a D status when the mouse is jerky or not responding. As p2p is not normally used in Mageia, testing that there are no regressions in normal wireless device setup/usage is good enough for this update.
CC: (none) => davidwhodgins
(In reply to Thomas Backlund from comment #12) > I see you got some misunderstanding here... > > Wifi P2P is not same p2p as torrents & co > > For wifi it's about Wifi Direct, meaning allowing devices with the > appropriate hardware to connect directly to each other via Wi-Fi without the > help of an access point... Oh. <Sigh.> I'm getting too old to keep up with both this and the technological advances in vegetable production at the same time.
Advisory: ======================== Updated wpa_supplicant packages fix a security vulnerability: A vulnerability was discovered in how wpa_supplicant processing P2P (Wi-Fi Direct) group information from active group owners. The actual parsing of that information validates field lengths appropriately, but processing of the parsed information misses a length check when storing a copy of the secondary device types. This can result in writing attacker controlled data into the peer entry after the area assigned for the secondary device type. The overflow can result in corrupting pointers for heap allocations. This can result in an attacker within radio range of the device running P2P discovery being able to cause unexpected behavior, including termination of the wpa_supplicant process and potentially arbitrary code execution. An attacker (or a system controlled by the attacker) needs to be within radio range of the vulnerable system to send a suitably constructed management frame that triggers a P2P peer device information to be created or updated. (CVE-2021-0326). References: - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-0326 - https://w1.fi/security/2020-2/wpa_supplicant-p2p-group-info-processing-vulnerability.txt ======================== Updated packages in core/updates_testing: ======================== wpa_supplicant-2.9-1.3.mga7 wpa_supplicant-gui-2.9-1.3.mga7 from wpa_supplicant-2.9-1.3.mga7.src.rpm Advisory pushed to SVN.
CC: (none) => ouaurelienCVE: (none) => CVE-2021-0326Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0075.html
Status: NEW => RESOLVEDResolution: (none) => FIXED