Fedora has issued an advisory today (July 12): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/WMXIHZROH2MHK2ATU7LWCID54SCKZA7Z/ The issue is fixed upstream in 7.5.0.
Status comment: (none) => Fixed upstream in 7.5.0
Assigning to Thierry, the active maintainer of 'libvirt'.
Assignee: bugsquad => thierry.vignaud
patch added in mga8: src: - libvirt-7.0.0-2.1.mga8
CC: (none) => mageiaAssignee: thierry.vignaud => qa-bugs
libvirt-devel-7.0.0-2.1.mga8 libvirt0-7.0.0-2.1.mga8 wireshark-libvirt-7.0.0-2.1.mga8 libnss_libvirt2-7.0.0-2.1.mga8 libvirt-docs-7.0.0-2.1.mga8 libvirt-utils-7.0.0-2.1.mga8 from libvirt-7.0.0-2.1.mga8.src.rpm
Status comment: Fixed upstream in 7.5.0 => (none)
Installation of the update causes mgaapplet to hang waiting for /bin/systemctl --quiet try-restart libvirt-guests.service # systemctl status libvirt-guests.service ● libvirt-guests.service - Suspend/Resume Running libvirt Guests Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled; vendor preset: disabled) Active: deactivating (stop) since Mon 2021-07-19 16:00:21 EDT; 9min ago Docs: man:libvirtd(8) https://libvirt.org Main PID: 2208 (code=exited, status=0/SUCCESS); Control PID: 98418 (libvirt-guests.) Tasks: 3 (limit: 3549) Memory: 4.1M CPU: 44ms CGroup: /system.slice/libvirt-guests.service ├─98418 /usr/bin/sh /usr/libexec/libvirt-guests.sh stop └─98425 virsh connect Jul 18 23:54:25 hodgins.homeip.net systemd[1]: Starting Suspend/Resume Running libvirt Guests... Jul 18 23:54:25 hodgins.homeip.net systemd[1]: Finished Suspend/Resume Running libvirt Guests. Jul 19 16:00:21 hodgins.homeip.net systemd[1]: Stopping Suspend/Resume Running libvirt Guests... After using "killall virsh", mgaapplet continued and showed the updated config files dialog.
CC: (none) => davidwhodgins
Advisory: ======================== Updated libvirt packages fix a security vulnerability: libvirt: insecure sVirt label generation (CVE-2021-3631). References: - https://bugs.mageia.org/show_bug.cgi?id=29252 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3631 - https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/WMXIHZROH2MHK2ATU7LWCID54SCKZA7Z/ ======================== Updated packages in core/updates_testing: ======================== lib(64)virt-devel-7.0.0-2.1.mga8 lib(64)virt0-7.0.0-2.1.mga8 wireshark-libvirt-7.0.0-2.1.mga8 lib(64)nss_libvirt2-7.0.0-2.1.mga8 libvirt-docs-7.0.0-2.1.mga8 libvirt-utils-7.0.0-2.1.mga8 from SRPM/ libvirt-7.0.0-2.1.mga8.src.rpm
CC: (none) => ouaurelien
CC: (none) => bequimao.de
Adding feedback tag due to comment 4
Keywords: (none) => feedback
Installed the package list in an instance which is a clone of Mageia 8 with running Virt-Manager. libvirt-utils is an upgrade here, not an install. No problem found during installation, no stalling. [root@mga8-tst2 ~]# journalctl -ab | grep libvirt Jul 21 15:49:05 mga8-tst2 dnsmasq[1471]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Jul 21 15:49:05 mga8-tst2 dnsmasq-dhcp[1471]: read /var/lib/libvirt/dnsmasq/default.hostsfile Jul 21 15:51:03 mga8-tst2 systemd[1]: libvirtd.service: Succeeded. Jul 21 15:51:03 mga8-tst2 systemd[1]: libvirtd.service: Unit process 1471 (dnsmasq) remains running after unit stopped. Jul 21 15:51:03 mga8-tst2 systemd[1]: libvirtd.service: Unit process 1472 (dnsmasq) remains running after unit stopped. Jul 21 15:58:35 mga8-tst2 [RPM][3193]: erase libvirt-utils-7.0.0-2.mga8.x86_64: success Jul 21 15:59:54 mga8-tst2 [RPM][3193]: install wireshark-libvirt-7.0.0-2.1.mga8.x86_64: success Jul 21 15:59:57 mga8-tst2 [RPM][3193]: install libvirt-utils-7.0.0-2.1.mga8.x86_64: success Jul 21 15:59:58 mga8-tst2 [RPM][3193]: install libvirt-docs-7.0.0-2.1.mga8.x86_64: success Jul 21 15:59:59 mga8-tst2 [RPM][3193]: install lib64nss_libvirt2-7.0.0-2.1.mga8.x86_64: success Jul 21 16:00:00 mga8-tst2 [RPM][3193]: erase libvirt-utils-7.0.0-2.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install wireshark-libvirt-7.0.0-2.1.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install libvirt-utils-7.0.0-2.1.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install libvirt-docs-7.0.0-2.1.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install lib64nss_libvirt2-7.0.0-2.1.mga8.x86_64: success [root@mga8-tst2 ~]# [root@mga8-tst2 ~]# systemctl list-units --all | grep libvirt libvirt-guests.service loaded inactive dead Suspend/Resume Running libvirt Guests libvirtd.service loaded inactive dead Virtualization daemon libvirtd-admin.socket loaded active listening Libvirt admin socket libvirtd-ro.socket loaded active listening Libvirt local read-only socket libvirtd.socket loaded active listening Libvirt local socket [root@mga8-tst2 ~]# Ulrich
Specifically, what I'm suggesting that the libvirt-guests.sh stop needs to be fixed to only run the virsh comand if there are guests to stop. Leaving mgaapplet hanging while installing the update is not ok. I'd previously used libvirt, and while I'd removed the guests, I forgot to disable the service.
(In reply to Dave Hodgins from comment #4) > Installation of the update causes mgaapplet to hang waiting for > /bin/systemctl --quiet try-restart libvirt-guests.service > I guess it is missing rights. Please confirm # cat /etc/group | egrep 'libvirt|kvm|qemu' kvm:x:996:qemu qemu:x:969: libvirt:x:469:bequimao I added the group libvirt manually. The units with a running guest look like this # systemctl list-units --all | grep libvirt libvirt-guests.service loaded inactive dead Suspend/Resume Running libvirt Guests libvirtd.service loaded active running Virtualization daemon libvirtd-admin.socket loaded active running Libvirt admin socket libvirtd-ro.socket loaded active running Libvirt local read-only socket libvirtd.socket loaded active running Libvirt local socket
$ egrep 'libvirt|kvm|qemu' /etc/group kvm:x:961:qemu,dave qemu:x:960:dave $ systemctl list-units --all | grep libvirt libvirt-guests.service loaded active exited Suspend/Resume Running libvirt Guests libvirtd.service loaded inactive dead Virtualization daemon libvirtd-admin.socket loaded active listening Libvirt admin socket libvirtd-ro.socket loaded active listening Libvirt local read-only socket libvirtd.socket loaded active listening Libvirt local socket $ systemctl -l --no-pager status libvirtd.service ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled) Active: inactive (dead) since Wed 2021-07-21 13:38:54 EDT; 1 day 2h ago TriggeredBy: ● libvirtd.socket ● libvirtd-admin.socket ● libvirtd-ro.socket Docs: man:libvirtd(8) https://libvirt.org Main PID: 2378 (code=exited, status=0/SUCCESS) CPU: 811ms Jul 21 13:36:54 hodgins.homeip.net systemd[1]: Starting Virtualization daemon... Jul 21 13:36:54 hodgins.homeip.net systemd[1]: Started Virtualization daemon. Jul 21 13:36:55 hodgins.homeip.net libvirtd[2378]: libvirt version: 7.0.0 Jul 21 13:36:55 hodgins.homeip.net libvirtd[2378]: hostname: hodgins.homeip.net Jul 21 13:36:55 hodgins.homeip.net libvirtd[2378]: internal error: Failed to apply firewall rules /usr/sbin/iptables -w --table filter --insert LIBVIRT_INP --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT: iptables: No chain/target/match by that name. Jul 21 13:38:54 hodgins.homeip.net systemd[1]: libvirtd.service: Succeeded.
Note that installing the update, which runs as root is what triggered the hangup.
Created attachment 12871 [details] Addendum: Log of Install/Upgrade of package list # dnf-qarepo.sh
Created attachment 12872 [details] Test of libvirt-guests.service Meanwhile I cloned and installed a MGA8 image to the test installation. libvirt-guests.service was unknown to me before. I configured it to shutdown and to resume any running guest at boot. So far everything works fine. No regression found, and I would give it an ok. @ David: If libvirt-guests.sh shutdowns and resumes guests that are not owned by root, it needs the rights accordingly. Best regards, Ulrich
Created attachment 12876 [details] Log of # dnf history undo <transaction no.> Sorry, my guesses proved to be wrong. And of course, the group libvirt has nothing to do with the rights of root. I ran into the same issue, when I tried to cleanup with # dnf history undo ... There was no running guest, and libvirt-guests.service enabled. The script stalled, and I had to kill the process in order to finish the transaction. Note that the error occurred when running the previous version libvirt-utils-7.0.0-2.mga8.x86_64 (downgrade). So it is a bug, but no regression. Best regards, Ulrich
While it is not a regression, so would normally be ok to push the security update and open a new bug report, the impact of the problem is such that I'm not ok with pushing the update as is. The specific problem occurs when the libvirt-utils postinstall scriptlet runs /usr/share/rpm-helper/add-service libvirt $1 libvirt-guests, which runs /bin/systemctl --quiet try-restart "$unit" In /usr/lib/systemd/system/libvirt-guests.service it runs ... /usr/libexec/libvirt-guests.sh stop It has a function ... run_virsh() { local uri="$1" shift if [ "x$uri" = xdefault ]; then virsh "$@" </dev/null else virsh -c "$uri" "$@" </dev/null fi } The problem is that virsh cannot connect and waits indefinitely. Either it needs to be modified not to call virsh if the libvirtd service is enabled, but no guests are running, or the program virsh needs to be modified to handle the state. Opinion?
I tried now to reproduce the bug under Fedora 34. libvirt-guests.service is provided there by libvirt-client-0:7.0.0-4.fc34.x86_64 libvirt-client-0:7.0.0-6.fc34.x86_64 So I enabled the service, and the idea was to downgrade libvirt-client with running guest, and later upgrade again without. The script stalled during downgrade (with running guest!) and I had to kill the script again. The subsequent upgrade (without guest!) however worked fine. No point to open a bug report on Fedora, as nobody would spend time on an error that occurred during downgrade. So we can't expect that the bug will be resolved in reasonable time, and as there is no regression my vote is to set the current bug report to "ok" and validate it. Best regards, Ulrich
openSUSE has issued an advisory for this today (August 10): https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/H5E4Y5JNZAR2C5I2WQMIIPVYTGLK5SBC/ As for the issue being discussed, basically this package is synced with Fedora, so we are unlikely to fix it until they do. Someone should report it to them.
I'm not ok with an update that may require a user to run "killall virsh" as root, just to have the update install ok. Keep in mind that this bug would/will be a release blocker for upgrading from Mageia 8 to 9. If it cannot be fixed without possibly requiring root user intervention during installation of an update, I'd rather obsolete ... $ urpmq --whatrequires-recursive libvirt-utils|sort -u cockpit-machines gnome-boxes koji-vm libvirt-java libvirt-java-devel libvirt-utils systemtap-runtime-virthost virt-install virt-manager due to the unfixed security update.
(In reply to David Walser from comment #17) > openSUSE has issued an advisory for this today (August 10): > https://lists.opensuse.org/archives/list/security-announce@lists.opensuse. > org/thread/H5E4Y5JNZAR2C5I2WQMIIPVYTGLK5SBC/ > > As for the issue being discussed, basically this package is synced with > Fedora, so we are unlikely to fix it until they do. Someone should report > it to them. openSUSE Leap 15.2 is not the current version. I tried to reproduce the error under Fedora, but the upgrade worked there. Subversion no. there is higher - 7.0.0-6. So we might test that version.
(In reply to Dave Hodgins from comment #18) > I'm not ok with an update that may require a user to run "killall virsh" as > root, just to have the update install ok. > > Keep in mind that this bug would/will be a release blocker for upgrading from > Mageia 8 to 9. > > If it cannot be fixed without possibly requiring root user intervention > during > installation of an update, I'd rather obsolete ... > $ urpmq --whatrequires-recursive libvirt-utils|sort -u > cockpit-machines > gnome-boxes > koji-vm > libvirt-java > libvirt-java-devel > libvirt-utils > systemtap-runtime-virthost > virt-install > virt-manager > > due to the unfixed security update. Not a release blocker, but a notification under errata. Do not forget that your finding was accidental, as you "forgot" to disable libvirt.guests. I actually use virt-manager, and so do others. But I never used libvirt.guests. Obsoleting it would be a blow to me.
Setting the bugreport to ok as discussed in the QA meeting of 12-08-2021. I will watch the libvirt.guests issue in MGA 8 and Cauldron. Ulrich
Whiteboard: (none) => MGA8-64-OKKeywords: feedback => (none)
Validating the update despite my misgivings. Hopefully it doesn't cause problems. Advisory in comment 5.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0399.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Created attachment 13589 [details] Excerpt of system-upgrade, checks of libvirt-guests I tested now a # dnf system-upgrade from Mga8 to Cauldron with libvirt-guests enabled and a running guest VM. The whole transaction went through successfully, which was the scope of the test. However, on reboot libvirt-guests and the VM where broken. Virt-Manager itself was operational. Tested with a second VM. I think, a reasonable user would shut down the guests and backup them, if production VMs are involved. So I think, no further investigation of failure needed. Best regards, Ulrich