Several security issues in qemu have been announced: http://openwall.com/lists/oss-security/2014/03/26/8 Patches are in this e-mail thread: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg04994.html Cauldron is not affected as the issues will be fixed in 2.0. They plan a 1.7.2 release to fix these, but it doesn't sound like there will be a newer 1.6.x release, so we'll probably need backported patches. Mageia 3 is also probably affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
Another security issue fixed upstream has been assigned a CVE: http://openwall.com/lists/oss-security/2014/04/18/5 Patch is here: https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg02016.html
Summary: qemu new security issues CVE-2014-014[2-7] => qemu new security issues CVE-2014-014[2-7] and CVE-2014-2894
Debian has issued an advisory for yet another security issue today (April 18): https://www.debian.org/security/2014/dsa-2909 from http://lwn.net/Vulnerabilities/595445/
Summary: qemu new security issues CVE-2014-014[2-7] and CVE-2014-2894 => qemu new security issues CVE-2014-014[2-7], CVE-2014-0150, and CVE-2014-2894
RedHat has issued an advisory for CVE-2014-014[2-8] on April 22: https://rhn.redhat.com/errata/RHSA-2014-0420.html
URL: (none) => http://lwn.net/Vulnerabilities/595779/Summary: qemu new security issues CVE-2014-014[2-7], CVE-2014-0150, and CVE-2014-2894 => qemu new security issues CVE-2014-014[2-8], CVE-2014-0150, and CVE-2014-2894
Ubuntu has issued an advisory which includes the issue I mentioned in Comment 1 and another not previously mentioned issue today (April 28): http://www.ubuntu.com/usn/usn-2182-1/ from http://lwn.net/Vulnerabilities/596590/
Summary: qemu new security issues CVE-2014-014[2-8], CVE-2014-0150, and CVE-2014-2894 => qemu new security issues CVE-2013-4544, CVE-2014-014[2-8], CVE-2014-0150, and CVE-2014-2894
Fedora has issued an advisory for all of these issues on May 1: https://lists.fedoraproject.org/pipermail/package-announce/2014-May/132409.html So we could sync all of their patches for Mageia 4.
More CVEs: CVE-2014-0223 http://openwall.com/lists/oss-security/2014/05/13/5 CVE-2014-0222 http://openwall.com/lists/oss-security/2014/05/13/4 CVE-2013-4541 CVE-2014-3461 http://openwall.com/lists/oss-security/2014/05/13/3 http://openwall.com/lists/oss-security/2014/05/13/7 The CVE-2014-3461 fix *should* be in 2.0.0, but the others are from the last couple of days, so probably aren't. This bug is getting out of hand, and patching all of these doesn't look like a very feasible plan. Maybe we'll just have to update all releases to 2.0.1 once it's out.
Summary: qemu new security issues CVE-2013-4544, CVE-2014-014[2-8], CVE-2014-0150, and CVE-2014-2894 => qemu new security issues CVE-2013-454[14], CVE-2014-014[2-8], CVE-2014-0150, CVE-2014-022[23], CVE-2014-2894, and CVE-2014-3461
Removing the CVEs from the bug title because there are WAY too many of them. They were: CVE-2013-454[14], CVE-2014-014[2-8], CVE-2014-0150, CVE-2014-022[23], CVE-2014-2894, and CVE-2014-3461 And now we're adding: CVE-2013-4148 -- CVE-2013-4151 CVE-2013-4526 - CVE-2013-4527 CVE-2013-4529 -- CVE-2013-4531 CVE-2013-4533 -- CVE-2013-4542 CVE-2013-6399 CVE-2014-0182 due to this Fedora advisory from May 13: https://lists.fedoraproject.org/pipermail/package-announce/2014-May/133345.html from http://lwn.net/Vulnerabilities/599081/ Perhaps we could sync Mageia 4 with Fedora 20. For Mageia 3, I just don't know.
Summary: qemu new security issues CVE-2013-454[14], CVE-2014-014[2-8], CVE-2014-0150, CVE-2014-022[23], CVE-2014-2894, and CVE-2014-3461 => qemu new security issues (entirely too many to mention)
LWN reference for CVE-2014-0222 CVE-2014-0223 CVE-2014-3461: http://lwn.net/Vulnerabilities/601900/ due to this Fedora advisory from June 1: https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134053.html
CVE-2014-3471 was announced today (June 23): http://openwall.com/lists/oss-security/2014/06/23/4 The message contains a link to a patch to fix it.
Yet another one (CVE-2014-5263) assigned August 15: http://openwall.com/lists/oss-security/2014/08/16/1 Upstream commit is linked.
Yet another one (CVE-2014-5388) assigned today (August 22): http://openwall.com/lists/oss-security/2014/08/22/5
And another today (September 8), CVE-2014-3615: http://openwall.com/lists/oss-security/2014/09/08/4
(In reply to David Walser from comment #12) > And another today (September 8), CVE-2014-3615: > http://openwall.com/lists/oss-security/2014/09/08/4 Fedora has issued an advisory for this on September 9: https://lists.fedoraproject.org/pipermail/package-announce/2014-September/137578.html from http://lwn.net/Vulnerabilities/611592/
CC: (none) => pterjan
Hmm there are some old packages in 4/update_testing for virt-manager/libusbredir (from March). Do you know what is the plan for them? Building against it or the one from release requires some changes in BuildRequires and currently the package has been changed to use the one in updates_testing.
(In reply to Pascal Terjan from comment #14) > Hmm there are some old packages in 4/update_testing for > virt-manager/libusbredir (from March). Do you know what is the plan for them? > Building against it or the one from release requires some changes in > BuildRequires and currently the package has been changed to use the one in > updates_testing. Oden tried to update it in Bug 13090 and Claire rejected it. I don't know what Oden wants to do about it.
CC: (none) => oe
In order to solve that, I applied all the qemu patches from Fedora 20 and pushed to mga4
CC: (none) => bruno
Thanks Bruno. That's a start. I wonder if there's any outstanding CVEs in their branch. Certainly there's ones in this bug that there's no mention of there, but I'm not sure the affected versions for each CVE. I also see the newest CVE they fixed there, CVE-2014-3640, doesn't appear to have been mentioned here yet. From what Pascal said, it sounds like we still have an outstanding issue with the virt-manager thing, but we can revert whatever BR changes there were and remove those things from updates_testing for now. For Mageia 3, unless we can backport what we end up with for Mageia 4, I guess there's probably no hope.
http://svnweb.mageia.org/packages/updates/4/qemu/current/SPECS/qemu.spec?r1=583807&r2=608737 is the change Pascal was talking about. I wonder what the implications of pushing the updated libusbredir would be, even if the virt-manager is a no-go.
Debian has issued advisories for some of these CVEs, including CVE-2014-3640, on October 4: https://www.debian.org/security/2014/dsa-3045 https://www.debian.org/security/2014/dsa-3044
LWN reference for CVE-2014-3640: http://lwn.net/Vulnerabilities/615606/
(In reply to David Walser from comment #15) > (In reply to Pascal Terjan from comment #14) > > Hmm there are some old packages in 4/update_testing for > > virt-manager/libusbredir (from March). Do you know what is the plan for them? > > Building against it or the one from release requires some changes in > > BuildRequires and currently the package has been changed to use the one in > > updates_testing. > > Oden tried to update it in Bug 13090 and Claire rejected it. I don't know > what Oden wants to do about it. Just nuke it.
Could a sysadmin remove virt-manager and libusbredir (and associated RPMs) from Mageia 4 updates_testing?
CC: (none) => sysadmin-bugs
Done
Thanks Pascal! OK, I reverted the BR change, so it will build against the core/release version of libusbredir. Assuming it builds, we can push it to QA as an update candidate for Mageia 4. As I mentioned earlier, Mageia 3 is probably hopeless at this point, so we can move forward with this. I'll probably try pushing it to the build system soon.
Patched package uploaded for Mageia 4. Dropping Mageia 3 from the whiteboard as we can no longer support this package. Advisory: ======================== Updated qemu packages fix security vulnerabilities: Michael S. Tsirkin discovered that QEMU incorrectly handled vmxnet3 devices. A local guest could possibly use this issue to cause a denial of service, or possibly execute arbitrary code on the host (CVE-2013-4544). Multiple integer overflow, input validation, logic error, and buffer overflow flaws were discovered in various QEMU block drivers. An attacker able to modify a disk image file loaded by a guest could use these flaws to crash the guest, or corrupt QEMU process memory on the host, potentially resulting in arbitrary code execution on the host with the privileges of the QEMU process (CVE-2014-0143, CVE-2014-0144, CVE-2014-0145, CVE-2014-0147). A buffer overflow flaw was found in the way the virtio_net_handle_mac() function of QEMU processed guest requests to update the table of MAC addresses. A privileged guest user could use this flaw to corrupt QEMU process memory on the host, potentially resulting in arbitrary code execution on the host with the privileges of the QEMU process (CVE-2014-0150). A divide-by-zero flaw was found in the seek_to_sector() function of the parallels block driver in QEMU. An attacker able to modify a disk image file loaded by a guest could use this flaw to crash the guest (CVE-2014-0142). A NULL pointer dereference flaw was found in the QCOW2 block driver in QEMU. An attacker able to modify a disk image file loaded by a guest could use this flaw to crash the guest (CVE-2014-0146). It was found that the block driver for Hyper-V VHDX images did not correctly calculate BAT (Block Allocation Table) entries due to a missing bounds check. An attacker able to modify a disk image file loaded by a guest could use this flaw to crash the guest (CVE-2014-0148). An out-of-bounds memory access flaw was found in the way QEMU's IDE device driver handled the execution of SMART EXECUTE OFFLINE commands. A privileged guest user could use this flaw to corrupt QEMU process memory on the host, which could potentially result in arbitrary code execution on the host with the privileges of the QEMU process (CVE-2014-2894). Two integer overflow flaws were found in the QEMU block driver for QCOW version 1 disk images. A user able to alter the QEMU disk image files loaded by a guest could use either of these flaws to corrupt QEMU process memory on the host, which could potentially result in arbitrary code execution on the host with the privileges of the QEMU process (CVE-2014-0222, CVE-2014-0223). Multiple buffer overflow, input validation, and out-of-bounds write flaws were found in the way the virtio, virtio-net, virtio-scsi, and usb drivers of QEMU handled state loading after migration. A user able to alter the savevm data (either on the disk or over the wire during migration) could use either of these flaws to corrupt QEMU process memory on the (destination) host, which could potentially result in arbitrary code execution on the host with the privileges of the QEMU process (CVE-2013-4148, CVE-2013-4151, CVE-2013-4535, CVE-2013-4536, CVE-2013-4541, CVE-2013-4542, CVE-2013-6399, CVE-2014-0182, CVE-2014-3461). An information leak flaw was found in the way QEMU's VGA emulator accessed frame buffer memory for high resolution displays. A privileged guest user could use this flaw to leak memory contents of the host to the guest by setting the display to use a high resolution in the guest (CVE-2014-3615). When guest sends udp packet with source port and source addr 0, uninitialized socket is picked up when looking for matching and already created udp sockets, and later passed to sosendto() where NULL pointer dereference is hit during so->slirp->vnetwork_mask.s_addr access Only guests using qemu user networking are affected (CVE-2014-3640). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4148 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4149 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4150 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4151 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4526 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4527 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4529 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4530 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4531 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4533 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4534 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4535 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4536 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4537 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4538 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4539 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4540 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4541 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4542 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6399 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0142 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0143 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0144 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0145 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0146 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0147 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0148 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0150 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0182 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0222 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0223 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3461 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3615 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3640 https://lists.fedoraproject.org/pipermail/package-announce/2014-May/132409.html https://lists.fedoraproject.org/pipermail/package-announce/2014-May/133345.html https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134053.html https://lists.fedoraproject.org/pipermail/package-announce/2014-September/137578.html https://lists.fedoraproject.org/pipermail/package-announce/2014-October/140130.html https://rhn.redhat.com/errata/RHSA-2014-0420.html https://rhn.redhat.com/errata/RHSA-2014-0704.html https://rhn.redhat.com/errata/RHSA-2014-0743.html https://rhn.redhat.com/errata/RHSA-2014-1669.html http://www.ubuntu.com/usn/usn-2182-1 ======================== Updated packages in core/updates_testing: ======================== qemu-1.6.2-1.2.mga4 qemu-img-1.6.2-1.2.mga4 from qemu-1.6.2-1.2.mga4.src.rpm
Assignee: joequant => qa-bugsWhiteboard: MGA3TOO => (none)
Severity: normal => major
Trying to test on mga4.1 x86_64 [root@vega ~]# urpmi qemu Unknown option: x To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (distrib1)") cyrus-sasl 2.1.26 4.mga4 x86_64 lib64brlapi0.6 4.5 9.mga4 x86_64 lib64sasl2-plug-anonymous 2.1.26 4.mga4 x86_64 (suggested) lib64spice-server1 0.12.4 4.mga4 x86_64 lib64vde3 2.3.2 7.mga4 x86_64 lib64xen3.0 4.3.1 2.mga4 x86_64 lib64yajl2 2.0.4 3.mga4 x86_64 (medium "Core Updates Testing (distrib5)") lib64usbredirparser1 0.6 1.mga4 x86_64 qemu 1.6.2 1.1.mga4 x86_64 qemu-img 1.6.2 1.1.mga4 x86_64 lib64usbredirparser1 failed to download qemu failed to download Changed mirror source twice. Both gave this error: [root@vega ~]# urpmi qemu Unknown option: x To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Updates Testing (distrib5)") lib64usbredirparser1 0.6 1.mga4 x86_64 qemu 1.6.2 1.1.mga4 x86_64 qemu-img 1.6.2 1.1.mga4 x86_64 124MB of additional disk space will be used. 14MB of packages will be retrieved. Proceed with the installation of the 3 packages? (Y/n) $MIRRORLIST: media/core/updates_testing/qemu-img-1.6.2-1.1.mga4.x86_64.rpm aria2 failed: exited with 3 Failed to download qemu-img-1.6.2-1.1.mga4.x86_64.rpm Retry? (y/N) Started with MageiaUpdate, which failed to offer qemu. urpmi.update -a, then [root@vega ~]# urpmi qemu Unknown option: x To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Updates Testing (distrib5)") qemu 1.6.2 1.2.mga4 x86_64 qemu-img 1.6.2 1.2.mga4 x86_64 123MB of additional disk space will be used. 14MB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) $MIRRORLIST: media/core/updates_testing/qemu-1.6.2-1.2.mga4.x86_64.rpm $MIRRORLIST: media/core/updates_testing/qemu-img-1.6.2-1.2.mga4.x86_64.rpm installing qemu-1.6.2-1.2.mga4.x86_64.rpm qemu-img-1.6.2-1.2.mga4.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ############################################# 1/2: qemu-img ############################################# 2/2: qemu ############################################# What next I wonder? Looks like kvm is needed... [root@vega ~]# urpmi kvm Unknown option: x Package qemu-1.6.2-1.2.mga4.x86_64 is already installed [lcl@vega ~]$ kvm kvm: Command not found. Help!
CC: (none) => tarazed25
@Len: it looks like your first mirrors wwere not fully up-to-date (or not fully synced), since they referenced the 1.1.mga4 of qemu but the current update candidate is 1.2.mga4. That's why it worked after urpmi.update -a in the last case. Maybe you are looking for "qemu-kvm" which is part of qemu? I don't know much about qemu usage though.
CC: (none) => remi
Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=6694#c3
Whiteboard: (none) => has_procedure
You need to have vt-d support in your prosessor (laptops don't have it) to use qemu-kvm here is arch linux guide to configure it. https://bbs.archlinux.org/viewtopic.php?id=162768 http://en.wikipedia.org/wiki/X86_virtualization
CC: (none) => ozkyster
Thanks for the links Otto. It appears that I would need two graphics cards so that rules me out.
I have no idea can it be used with only one graphics cards i have not tested it so maybe somebody who knows lot of these things can help more.
You can surely use it without a second graphic card. That's most of my conf.
The easiest way to test qemu is probably using virt-manager. The problem is to get virt-manager working (it uses the libvirt daemon, for example), but could be worth a try. If you want to know if your machine supports KVM, check the flags in /proc/cpuinfo: vmx = Intel virtualization; svm = AMD virtualization. Qemu kan work without kvm in simulation mode but that's very slow. Virt-manager warns about that.
CC: (none) => cjw
How I would test qemu basically (on my x86_64): wget ftp://ftp.snt.utwente.nl/pub/os/linux/mageia/distrib/cauldron/x86_64/install/images/boot.iso qemu-kvm -net user -net nic,model=virtio -cdrom boot.iso -boot d -m 512 Choose FTP or HTTP Select DHCP Select a mirror for Mageia 5 Check that stage2 is starting
Testing complete mga4 64 with Pascal's handy one liner.
Whiteboard: has_procedure => has_procedure mga4-64-ok
Testing complete mga4 32
Whiteboard: has_procedure mga4-64-ok => has_procedure mga4-32-ok mga4-64-ok
Validating. Advisory uploaded. Could sysadmin please push to 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: has_procedure mga4-32-ok mga4-64-ok => has_procedure advisory mga4-32-ok mga4-64-ok
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0426.html
Status: NEW => RESOLVEDResolution: (none) => FIXED