Description of problem: A regression was introduced upstream that can be used to reopen disk probing. Version-Release number of selected component (if applicable): libvirt-0.9.0-1.mga1.src.rpm How reproducible: N/A Patch: https://www.redhat.com/archives/libvir-list/2011-May/msg01935.html Possible update text: Eric Blake discovered that libvirt had an off-by-one error which could be used to reopen disk probing and bypass the fix for CVE-2010-2238. A privileged attacker in the guest could exploit this to read arbitrary files on the host. This issue is identified at mitre.org by CVE-2011-2178. Updated packages correct this issue.
Whee, and right after I push submit, another one: It has been found that calling VirDomainGetVcpus with bogus parameters can lead to integer overflow and subsequent heap corruption. A remote attacker could use this flaw to crash libvirtd (DoS). Upstream patch: https://www.redhat.com/archives/libvir-list/2011-June/msg01278.html I'll add an updated advisory text once the CVE indentifier has been issued
no interest in this, closing
Status: NEW => RESOLVEDResolution: (none) => OLD
Stew, I understand your frustration in the lack of follow up given to reported security problems, but I think closing security bugs which have not been solved is not the right way to go. Let's try to keep those issues on the radar at least.
Keywords: (none) => SecurityStatus: RESOLVED => REOPENEDCC: (none) => remcoResolution: OLD => (none)
CC: (none) => saispo
CC: (none) => boklm, misc
The 2nd patch apply fine, but not the first one :/
For info, the commits are b598ac555c8fe67ffc39ac8ef25fe7e6b28ae3f2 774b21c163845170c9ffa873f5720d318812eaf6 And the code change quite a bit, and I am not sure to understand the problem of the fix.
Ok, so I have a working patch, expcet there is a missing macros in gnulib. I guess I need to cut and past .
This one go submitted, it is up to QA to test ( but I do not have test instruction nor advisory for now ).
Assignee: bugsquad => qa-bugs
Depends on: (none) => 2594
CC: (none) => stormiDepends on: 2594 => (none)
Can somebody supply testing procedures please.
CC: (none) => eeeemail
We can't check that the fix is ok, but we can check that the package works. Misc told me that if I can make the following work, it should be ok : https://kashyapc.wordpress.com/2011/08/18/unattended-guest-install-with-a-local-kickstart/
Summary: plug regression introduced in disk probe logic => libvirt security update: plug regression introduced in disk probe logic
The following test day page from fedora can help find testing procedures: https://fedoraproject.org/wiki/Test_Day:2011-09-15_Virtualization
x86_64 Followed the kickstart thing from comment 9. After starting libvirtd, it created a virtual disk image and downloaded stuff and booted and sat using 144% CPU for a couple of hours after "Trying to unpack rootfs image as initramfs..." until I killed "qemu kvm" so, although the installation might not have been 100% functional, the process of installation appears to have completed. If this is sufficient testing then I'm happy to call this one cooked.
Misc can you confirm whether the above testing validates the update please. Thanks.
This is hard to validate, other than following the procedure above - which we were unable to do i586 previously for python-virtinst, which was validated. The installation process appeared to complete by downloading some bits and attempting to boot as it did for python-virtinst. Without fully understanding, I consider the process to have worked, mostly, and what didnt work is most likely not down to disk probing and more to do with me not using libvirt/qemu properly. Is it safe to validate this update?? Some dev input would be appreciated. Thankyou.
Assigning to misc to check last few comments so we can validate this. Please reassign back to QA when you've had a look. Thanks.
CC: (none) => qa-bugsHardware: i586 => AllAssignee: qa-bugs => misc
I think using the script I posted ( viviane.sh , http://www.mail-archive.com/mageia-dev@mageia.org/msg07340.html ) could be used to validate everything. It requires a good internet connexion ( ie, enough to do a network installation do not attempt to do it if there is quota ), and enough disk space. Now, the question is "what did you try exactly", and to what point did the installation went ? Ie, it started to download some stuff do not tell if it worked enough to install a distribution or if it didn't even start the installation :/
Please see comment 11. The original website about kickstart gave a bad link, the F15 media it was using wouldn't work so I tried with a different distro. I can't remember which it was now :\ I'll try viviane. Does it require network bridging again? I have 7.1G free space in / partition x86_64.. will this be enough?
(In reply to comment #16) > I'll try viviane. Does it require network bridging again? > > I have 7.1G free space in / partition x86_64.. will this be enough? I think so
Assignee: misc => qa-bugs
I'm trying viviane.sh So far, I installed qemu, python-virtinst, libvirt0, set up the network bridge, started libvirtd service # ./viviane.sh Name "main::o" used only once: possible typo at /tmp/viviane_DWjpS/auto_inst.cfg.pl line 3. /tmp/viviane_DWjpS/auto_inst.cfg.pl syntax OK setfacl: Option -m: Invalid argument near character 3 It is sat doing something/nothing with no signs of action. It doesn't appear to be eating into the disk space either.
Oh, I tell a lie, it is slowly eating disk space. Patience is a 'virt'ue I guess!
Created attachment 988 [details] MDV2010.2 Running after installing with viviane.sh It took over an hour to install but finally did. It shut down rather than rebooting but using virt-manager I was able to watch it install and then take the screenshot attached when I started it manually. I don't have the disk space to test this i586, not sure if Stormi or Dave have, so if nobody objects I will validate?
no objection from me
I seem to remember Dave had problems with libvirt on his computer anyway so I'll validate. Advisory ------------------ Eric Blake discovered that libvirt had an off-by-one error which could be used to reopen disk probing and bypass the fix for CVE-2010-2238. A privileged attacker in the guest could exploit this to read arbitrary files on the host. This issue is identified at mitre.org by CVE-2011-2178. Updated packages correct this issue. Also, it was found that calling VirDomainGetVcpus with bogus parameters can lead to integer overflow and subsequent heap corruption. A remote attacker could use this flaw to crash libvirtd (DoS). ------------------ SRPM: libvirt-0.9.0-1.1.mga1.src.rpm Could sysadmin push this from core/updates_testing to core/updates Thankyou!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Update pushed.
Status: REOPENED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
CC: boklm => (none)