SUSE has issued an advisory on May 6: http://lists.suse.com/pipermail/sle-security-updates/2020-May/006795.html The issues are fixed upstream in 6.1.0.
Assigning to tv as the principle maintainer.
Assignee: bugsquad => thierry.vignaud
Ubuntu has issued an advisory for this today (May 21): https://usn.ubuntu.com/4371-1/
Severity: normal => major
References: CVE-2020-10703 https://bugzilla.redhat.com/show_bug.cgi?id=1790725 Introduced by: https://libvirt.org/git/?p=libvirt.git;a=commit;h=5d5c732d748d644ec14626bce448e84bdc4bd93e (v3.10.0-rc1) Fixed by: https://libvirt.org/git/?p=libvirt.git;a=commit;h=dfff16a7c261f8d28e3abe60a47165f845fa952f (CVE-2020-10703) CVE-2020-12430 Fixed by: https://libvirt.org/git/?p=libvirt.git;a=commit;h=9bf9e0ae6af38c806f4672ca7b12a6b38d5a9581 (v6.1.0-rc1) Introduced in: https://libvirt.org/git/?p=libvirt.git;a=commit;h=d1eac92784573559b6fd56836e33b215c89308e3 (v4.10.0-rc1) https://bugzilla.redhat.com/show_bug.cgi?id=1804548 https://bugzilla.redhat.com/show_bug.cgi?id=1828190 from: libvirt-5.5.0-1.1.mga7
Assignee: thierry.vignaud => qa-bugsCC: (none) => mageia
Advisory: ======================== Updated libvirt packages fix security vulnerability: It was discovered that libvirt incorrectly handled an active pool without a target path. A remote attacker could possibly use this issue to cause libvirt to crash, resulting in a denial of service (CVE-2020-10703). It was discovered that libvirt incorrectly handled memory when retrieving certain domain statistics. A remote attacker could possibly use this issue to cause libvirt to consume resources, resulting in a denial of service (CVE-2020-12430). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10703 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12430 https://usn.ubuntu.com/4371-1/ ======================== Updated packages in core/updates_testing: ======================== libvirt-docs-5.5.0-1.1.mga7 libvirt0-5.5.0-1.1.mga7 libvirt-devel-5.5.0-1.1.mga7 libvirt-utils-5.5.0-1.1.mga7 wireshark-libvirt-5.5.0-1.1.mga7 libnss_libvirt2-5.5.0-1.1.mga7 from libvirt-5.5.0-1.1.mga7.src.rpm
MGA7-64 Plasma on Lenovo B50 No installation issues. Ref bug 21826 for testing, also bug 24757. Installed virt-manager # systemctl start libvirtd # systemctl -l status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-05-26 13:21:44 CEST; 16s ago Docs: man:libvirtd(8) https://libvirt.org Main PID: 4343 (libvirtd) Tasks: 19 (limit: 32768) Memory: 13.9M CGroup: /system.slice/libvirtd.service ├─4343 /usr/sbin/libvirtd ├─4463 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexe> └─4464 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexe> May 26 13:21:44 mach5.hviaene.thuis dnsmasq[4463]: started, version 2.80 cachesize 150 May 26 13:21:44 mach5.hviaene.thuis dnsmasq[4463]: compile time options: IPv6 GNU-getopt DBus i18n IDN2 DHCP DHCPv6 no-Lua> May 26 13:21:44 mach5.hviaene.thuis dnsmasq-dhcp[4463]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h May 26 13:21:44 mach5.hviaene.thuis dnsmasq-dhcp[4463]: DHCP, sockets bound exclusively to interface virbr0 May 26 13:21:44 mach5.hviaene.thuis dnsmasq[4463]: reading /etc/resolv.conf May 26 13:21:44 mach5.hviaene.thuis dnsmasq[4463]: using nameserver 192.168.2.1#53 May 26 13:21:44 mach5.hviaene.thuis dnsmasq[4463]: using nameserver 212.71.0.33#53 May 26 13:21:44 mach5.hviaene.thuis dnsmasq[4463]: read /etc/hosts - 2 addresses May 26 13:21:44 mach5.hviaene.thuis dnsmasq[4463]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses May 26 13:21:44 mach5.hviaene.thuis dnsmasq-dhcp[4463]: read /var/lib/libvirt/dnsmasq/default.hostsfile Then as normal user: $ virt-manager But here something happens that was nt mentioned in the older bugs: KDE policy jumps in and requires the root password. I can cancel that dialogue or not, in either way the virt-manager runs as a normal user. I know that because I selected by coincidence an iso file which is owned and exclusively accessible by root. Anyway, the virt-manager seems to operate well in its first stages. I cannot complete the tesst because of disk space constraints. I will not object to an OKif someone else can do a better test.
CC: (none) => herman.viaene
@Herman You'll have to create a group "libvirt" and assign your user to it. Installed packages: lib64virt0-5.5.0-1.1.mga7 lib64virt-glib1.0_0-2.0.0-1.mga7 lib64virt-glib-gir1.0-2.0.0-1.mga7 libvirt-utils-5.5.0-1.1.mga7 python3-libvirt-5.5.0-1.mga7 virt-manager-2.1.0-2.mga7 virt-manager-common-2.1.0-2.mga7 I have Qemu/KvM and Virt-Manager running on Mageia 7 as host, and also Mageia 7 as test guest. No regression found. Setting OK. Ulrich
Whiteboard: (none) => MGA7-64-OKCC: (none) => bequimao.de
Installed and tested without issues. System: Mageia 7, x86_64, QEMU/KVM, virt-manager, Intel CPU, nVidia GPU using nvidia340 proprietary driver. Guest system: Mageia 7, Mageia Cauldron, FuryBSD 12.1, Windows 7, Windows 10 Tested using virsh with a variety of command. No issues or regressions noticed. $ uname -a Linux marte 5.6.14-desktop-2.mga7 #1 SMP Wed May 20 23:14:20 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep virt | sort lib64virt0-5.5.0-1.1.mga7 lib64virt-glib1.0_0-2.0.0-1.mga7 lib64virt-glib-gir1.0-2.0.0-1.mga7 libvirt-utils-5.5.0-1.1.mga7 python3-libvirt-5.5.0-1.mga7 virt-manager-2.1.0-2.mga7 virt-manager-common-2.1.0-2.mga7 $ LANGUAGE=C virsh list --all Id Name State ------------------------------------ - mageia_7 shut off - mageia_cauldron shut off - windows_10 shut off - windows_7 shut off - furybsd_12 shut off $ systemctl status libvirtd.service ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2020-05-28 23:29:29 WEST; 9min ago Docs: man:libvirtd(8) https://libvirt.org Main PID: 21477 (libvirtd) Tasks: 19 (limit: 32768) Memory: 41.8M CGroup: /system.slice/libvirtd.service ├─21477 /usr/sbin/libvirtd ├─21577 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper └─21578 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper mai 28 23:30:26 marte dnsmasq[21577]: reading /etc/resolv.conf mai 28 23:30:26 marte dnsmasq[21577]: using nameserver 127.0.0.53#53 <SNIP>
CC: (none) => mageia
Looks good to me. Validating. Advisory in Comment 4.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0250.html
Status: NEW => RESOLVEDResolution: (none) => FIXED