Security and bugfixes, advisory will follow SRPMS: kernel-linus-5.10.43-1.mga8.src.rpm i586: kernel-linus-5.10.43-1.mga8-1-1.mga8.i586.rpm kernel-linus-devel-5.10.43-1.mga8-1-1.mga8.i586.rpm kernel-linus-devel-latest-5.10.43-1.mga8.i586.rpm kernel-linus-doc-5.10.43-1.mga8.noarch.rpm kernel-linus-latest-5.10.43-1.mga8.i586.rpm kernel-linus-source-5.10.43-1.mga8-1-1.mga8.noarch.rpm kernel-linus-source-latest-5.10.43-1.mga8.noarch.rpm x86_64: kernel-linus-5.10.43-1.mga8-1-1.mga8.x86_64.rpm kernel-linus-devel-5.10.43-1.mga8-1-1.mga8.x86_64.rpm kernel-linus-devel-latest-5.10.43-1.mga8.x86_64.rpm kernel-linus-doc-5.10.43-1.mga8.noarch.rpm kernel-linus-latest-5.10.43-1.mga8.x86_64.rpm kernel-linus-source-5.10.43-1.mga8-1-1.mga8.noarch.rpm kernel-linus-source-latest-5.10.43-1.mga8.noarch.rpm
Mga7 rpms: SRPMS: kernel-linus-5.10.43-1.mga7.src.rpm i586: kernel-linus-5.10.43-1.mga7-1-1.mga7.i586.rpm kernel-linus-devel-5.10.43-1.mga7-1-1.mga7.i586.rpm kernel-linus-devel-latest-5.10.43-1.mga7.i586.rpm kernel-linus-doc-5.10.43-1.mga7.noarch.rpm kernel-linus-latest-5.10.43-1.mga7.i586.rpm kernel-linus-source-5.10.43-1.mga7-1-1.mga7.noarch.rpm kernel-linus-source-latest-5.10.43-1.mga7.noarch.rpm x86_64: kernel-linus-5.10.43-1.mga7-1-1.mga7.x86_64.rpm kernel-linus-devel-5.10.43-1.mga7-1-1.mga7.x86_64.rpm kernel-linus-devel-latest-5.10.43-1.mga7.x86_64.rpm kernel-linus-doc-5.10.43-1.mga7.noarch.rpm kernel-linus-latest-5.10.43-1.mga7.x86_64.rpm kernel-linus-source-5.10.43-1.mga7-1-1.mga7.noarch.rpm kernel-linus-source-latest-5.10.43-1.mga7.noarch.rpm
Whiteboard: (none) => MGA7TOOSummary: Update request: kernel-linus-5.10.43-1.mga8 => Update request: kernel-linus-5.10.43-1.mga8/7
Installed linus and desktop kernels. Rebooted to Mate on linus. Kernel: 5.10.43-1.mga8 x86_64 10-Core Intel Core i9-7900X [MT MCP] NVIDIA GP102 [GeForce GTX 1080 Ti] driver: nvidia v: 460.84 No regressions noted. USB external disks and NFS shares already mounted. Bluetooth audio and pulseaudio working fine. Ran a few stress tests. All OK. Leaving this to run on production machine for a while.
CC: (none) => tarazed25
Advisory, added to svn: type: security subject: Updated kernel-linus packages fix security vulnerabilities CVE: - CVE-2020-24586 - CVE-2020-24587 - CVE-2020-24588 - CVE-2020-26139 - CVE-2020-26141 - CVE-2020-26145 - CVE-2020-26147 - CVE-2021-3564 - CVE-2021-3573 - CVE-2021-3587 - CVE-2021-28691 src: 8: core: - kernel-linus-5.10.43-1.mga8 7: core: - kernel-linus-5.10.43-1.mga7 description: | This kernel-linus update is based on upstream 5.10.43 and fixes atleast the following security issues: The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that received fragments be cleared from memory after (re)connecting to a network. Under the right circumstances, when another device sends fragmented frames encrypted using WEP, CCMP, or GCMP, this can be abused to inject arbitrary network packets and/or exfiltrate user data (CVE-2020-24586). The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that all fragments of a frame are encrypted under the same key. An adversary can abuse this to decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed (CVE-2020-24587). The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that the A-MSDU flag in the plaintext QoS header field is authenticated. Against devices that support receiving non-SSP A-MSDU frames (which is mandatory as part of 802.11n), an adversary can abuse this to inject arbitrary network packets (CVE-2020-24588). An issue was discovered in the kernel. An Access Point (AP) forwards EAPOL frames to other clients even though the sender has not yet successfully authenticated to the AP. This might be abused in projected Wi-Fi networks to launch denial-of-service attacks against connected clients and makes it easier to exploit other vulnerabilities in connected clients (CVE-2020-26139). An issue was discovered in the kernel ath10k driver. The Wi-Fi implementation does not verify the Message Integrity Check (authenticity) of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets in WPA or WPA2 networks that support the TKIP data-confidentiality protocol (CVE-2020-26141). An issue was discovered in the kernel ath10k driver. The WEP, WPA, WPA2, and WPA3 implementations accept second (or subsequent) broadcast fragments even when sent in plaintext and process them as full unfragmented frames. An adversary can abuse this to inject arbitrary network packets independent of the network configuration (CVE-2020-26145). An issue was discovered in the Linux kernel 5.8.9. The WEP, WPA, WPA2, and WPA3 implementations reassemble fragments even though some of them were sent in plaintext. This vulnerability can be abused to inject packets and/ or exfiltrate selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP data-confidentiality protocol is used (CVE-2020-26147). A double-free memory corruption in the Linux kernel HCI device initialization subsystem was found in the way user attach malicious HCI TTY Bluetooth device. A local user could use this flaw to crash the system (CVE-2021-3564). A use after free vulnerability has been found in the hci_sock_bound_ioctl() function of the Linux kernel. It can allow attackers to corrupt kernel heaps (kmalloc-8k to be specific) and adopt further exploitations (CVE-2021-3573). There is a null pointer dereference in llcp_sock_getname in net/nfc/ llcp_sock.c of the Linux kernel. An unprivileged user can trigger this bug and cause denial of service (CVE-2021-3587). There is a guest triggered use-after-free in Linux xen-netback. A malicious or buggy network PV frontend can force Linux netback to disable the interface and terminate the receive kernel thread associated with queue 0 in response to the frontend sending a malformed packet. Such kernel thread termination will lead to a use-after-free in Linux netback when the backend is destroyed, as the kernel thread associated with queue 0 will have already exited and thus the call to kthread_stop will be performed against a stale pointer. A malicious or buggy frontend driver can trigger a dom0 crash. Privilege escalation and information leaks cannot be ruled out. (CVE-2021-28691 / XSA-374). For other upstream fixes, see the referenced changelogs. references: - https://bugs.mageia.org/show_bug.cgi?id=29107 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.42 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.43 - https://xenbits.xen.org/xsa/advisory-374.html
Keywords: (none) => advisory
flushing out
Whiteboard: MGA7TOO => MGA7TOO, MGA8-64-OK, MGA7-64-OKCC: (none) => sysadmin-bugsKeywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0258.html
Status: NEW => RESOLVEDResolution: (none) => FIXED