A CVE was assigned for a security issue in qemu on January 16: http://openwall.com/lists/oss-security/2016/01/16/6 RedHat has it rated as low severity, so we can just include this fix in our next update. Reproducible: Steps to Reproduce:
Another CVE request, RH rated medium severity: http://openwall.com/lists/oss-security/2016/01/19/10
(In reply to David Walser from comment #1) > Another CVE request, RH rated medium severity: > http://openwall.com/lists/oss-security/2016/01/19/10 CVE-2016-1981: http://openwall.com/lists/oss-security/2016/01/22/1
Summary: qemu new security issue CVE-2016-1922 => qemu new security issue CVE-2016-1922 and CVE-2016-1981
(In reply to David Walser from comment #0) > A CVE was assigned for a security issue in qemu on January 16: > http://openwall.com/lists/oss-security/2016/01/16/6 LWN reference for CVE-2016-1922: http://lwn.net/Vulnerabilities/673466/ from this Fedora advisory from January 23: https://lists.fedoraproject.org/pipermail/package-announce/2016-January/175967.html
CVE request for another issue: http://www.openwall.com/lists/oss-security/2016/01/29/2
And another: http://openwall.com/lists/oss-security/2016/01/29/6
(In reply to David Walser from comment #4) > CVE request for another issue: > http://www.openwall.com/lists/oss-security/2016/01/29/2 CVE-2016-2197: http://www.openwall.com/lists/oss-security/2016/01/30/1 (In reply to David Walser from comment #5) > And another: > http://openwall.com/lists/oss-security/2016/01/29/6 CVE-2016-2198: http://www.openwall.com/lists/oss-security/2016/01/30/2
Summary: qemu new security issue CVE-2016-1922 and CVE-2016-1981 => qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78]
Ubuntu has issued an advisory for this today (Feburary 3): http://www.ubuntu.com/usn/usn-2891-1/
URL: (none) => http://lwn.net/Vulnerabilities/674496/
Another new issue, CVE-2016-2391: http://openwall.com/lists/oss-security/2016/02/16/5
Summary: qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78] => qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-2391
And another, CVE-2016-2392: http://openwall.com/lists/oss-security/2016/02/16/8
Summary: qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-2391 => qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12]
Assigning to maintainer.
Assignee: bugsquad => joequant
CVE request for another issue: http://openwall.com/lists/oss-security/2016/02/22/3
(In reply to David Walser from comment #11) > CVE request for another issue: > http://openwall.com/lists/oss-security/2016/02/22/3 CVE-2016-2538: http://openwall.com/lists/oss-security/2016/02/23/8
Summary: qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12] => qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538
Yet another CVE request: http://openwall.com/lists/oss-security/2016/03/01/1
(In reply to David Walser from comment #13) > Yet another CVE request: > http://openwall.com/lists/oss-security/2016/03/01/1 CVE-2015-881[78] assigned: http://openwall.com/lists/oss-security/2016/03/01/10
Summary: qemu new security issues CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538 => qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538
Yet another CVE request: http://openwall.com/lists/oss-security/2016/03/02/8
(In reply to David Walser from comment #15) > Yet another CVE request: > http://openwall.com/lists/oss-security/2016/03/02/8 CVE-2016-2841: http://openwall.com/lists/oss-security/2016/03/03/1
Summary: qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538 => qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841
And another CVE request: http://openwall.com/lists/oss-security/2016/03/03/9
And yet another CVE request: http://openwall.com/lists/oss-security/2016/03/04/1
(In reply to David Walser from comment #17) > And another CVE request: > http://openwall.com/lists/oss-security/2016/03/03/9 CVE-2016-2857: http://openwall.com/lists/oss-security/2016/03/07/3 (In reply to David Walser from comment #18) > And yet another CVE request: > http://openwall.com/lists/oss-security/2016/03/04/1 CVE-2016-2858: http://openwall.com/lists/oss-security/2016/03/07/4
Summary: qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841 => qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78]
LWN reference for... CVE-2016-2841 CVE-2016-2538 CVE-2016-2392 CVE-2016-2391 CVE-2016-2857 CVE-2015-8817 CVE-2015-8818 CVE-2016-2858: http://lwn.net/Vulnerabilities/680800/
Two new CVE requests: http://openwall.com/lists/oss-security/2016/04/11/4 http://openwall.com/lists/oss-security/2016/04/11/6
(In reply to David Walser from comment #21) > Two new CVE requests: > http://openwall.com/lists/oss-security/2016/04/11/4 CVE-2016-4001: http://openwall.com/lists/oss-security/2016/04/12/6 > http://openwall.com/lists/oss-security/2016/04/11/6 CVE-2016-4002: http://openwall.com/lists/oss-security/2016/04/12/7
Summary: qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78] => qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78], CVE-2016-400[12]
CVE-2016-4020: http://openwall.com/lists/oss-security/2016/04/14/3
Summary: qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78], CVE-2016-400[12] => qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78], CVE-2016-400[12], CVE-2016-4020
CVE-2016-4037: http://openwall.com/lists/oss-security/2016/04/18/6
Summary: qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78], CVE-2016-400[12], CVE-2016-4020 => qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78], CVE-2016-400[12], CVE-2016-4020, CVE-2016-4037
CVE-2016-3710 and CVE-2016-3712: http://openwall.com/lists/oss-security/2016/05/09/3 http://openwall.com/lists/oss-security/2016/05/09/4
Summary: qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78], CVE-2016-400[12], CVE-2016-4020, CVE-2016-4037 => qemu new security issues CVE-2015-881[78], CVE-2016-1922, CVE-2016-1981, CVE-2016-219[78], CVE-2016-239[12], CVE-2016-2538, CVE-2016-2841, CVE-2016-285[78], CVE-2016-400[12], CVE-2016-4020, CVE-2016-4037, CVE-2016-371[02]
Assigning to qemu's new maintainer. Good luck! :)
Assignee: joequant => thierry.vignaud
We could rebase from 2.1.3 to 2.3.x and follow FC22 for security fixes. WDYT David?
(In reply to Thierry Vignaud from comment #27) > We could rebase from 2.1.3 to 2.3.x and follow FC22 for security fixes. > WDYT David? That sounds like a good idea. We could also go with 2.4.x from Fedora 23, as Fedora 22 will only be supported for a couple more months. We'd have to check that none of the security fixes are missed, as Fedora has been spotty with fixing them at times.
Well, mga6 will hopefully be released on schedule (end of June) and thus we could hope for FC22 to be EOL just a couple monthes before mga5 will. Anyway, I'm uploading qemu-2.3.1, we can then check that the following still works nicely: - virt-manager - quick qemu run Then we can later rebase to 2.4.x as in FC23 and recheck qemu/virt-mananger For the record, here's the changes that the current rebase will push to our users: http://wiki.qemu.org/ChangeLog/2.2 http://wiki.qemu.org/ChangeLog/2.3 There's not that much incompatible changes so I don't expect fallures when testing. With 2.4, there would be more incompatible changes but not with the default emulated chipset. For mga6, I expect it'll be easier to maintain it after all the changes I did. It should be especially easier to rebase over FC work.
qemu-2.3.1-2.11.mga5 was updated in core/release_updates
Source RPM: qemu-2.1.3-2.11.mga5.src.rpm => qemu-2.3.1-2.11.mga5.src.rpm
(In reply to David Walser from comment #25) > CVE-2016-3710 and CVE-2016-3712: > http://openwall.com/lists/oss-security/2016/05/09/3 > http://openwall.com/lists/oss-security/2016/05/09/4 LWN reference for CVE-2016-3710: http://lwn.net/Vulnerabilities/686857/ LWN reference for CVE-2016-3712: http://lwn.net/Vulnerabilities/686861/
(In reply to Thierry Vignaud from comment #30) > qemu-2.3.1-2.11.mga5 was updated in core/release_updates qemu-2.3.1-2.11.mga5 qemu-img-2.3.1-2.11.mga5 from qemu-2.3.1-2.11.mga5.src.rpm I don't see these CVEs in the diff: CVE-2015-881[78] CVE-2016-2198 CVE-2016-2391 CVE-2016-2858 CVE-2016-400[12] CVE-2016-4020 CVE-2016-4037 CVE-2016-371[02] I do see these CVEs, that are a part of this bug, have been fixed: CVE-2016-1922 CVE-2016-1981 CVE-2016-2197 CVE-2016-2392 CVE-2016-2538 CVE-2016-2841 CVE-2016-2857
either FC is sloppy or they don't apply to that branch. I suggest: - first testing/pushing this 2.3.1 rebase, - then rebasing over f23/2.4.x (where they're fixed) the testing again WDYT?
(In reply to Thierry Vignaud from comment #33) > either FC is sloppy or they don't apply to that branch. > I suggest: > - first testing/pushing this 2.3.1 rebase, > - then rebasing over f23/2.4.x (where they're fixed) the testing again > > WDYT? I don't see a need to make QA test this twice in a row. Let's just go for 2.4.x now if that's what we're going to do.
"as you wish my lord"
pkg updated to qemu-2.4.1-2.11.mga5 (yes I forgot to reset the release) qemu-2.4.1-3.mga5 is currently building with additional BRs for new features between qemu 2.2 & 2.4
Source RPM: qemu-2.3.1-2.11.mga5.src.rpm => qemu-2.4.1-2.11.mga5.src.rpm
Thanks. It looks like we're still missing this commit, which contains most of the missing CVEs: http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/commit/?h=f23&id=e0a4eb72191f5f0b8974d13920f6205a1b1901f9
CVE-2015-881[78] are unfixed in 2.3.1, but we're fixing them by updating to 2.4.1. CVE-2016-4002 hasn't been fixed yet by Fedora in F23, the patch is here: https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg01131.html CVE-2016-4020 hasn't been fixed yet by Fedora, the patch is here: https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg01106.html
Source RPM: qemu-2.4.1-2.11.mga5.src.rpm => qemu-2.4.1-4.mga5.src.rpm
(In reply to David Walser from comment #37) > Thanks. It looks like we're still missing this commit, which contains most > of the missing CVEs: > http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/commit/ > ?h=f23&id=e0a4eb72191f5f0b8974d13920f6205a1b1901f9 I see you added the comments, but not the actual patches from this commit...
They were all in patch 1000 as hinted by David. I've replaced them by FC split patches (my git checkout wasn't uptodate)
Source RPM: qemu-2.4.1-4.mga5.src.rpm => qemu-2.4.1-5.mga5.src.rpm
LWN reference for CVE-2016-4020: http://lwn.net/Vulnerabilities/687235/
Thanks Thierry! Assigning to QA now. Advisory to come next week. qemu-2.4.1-5.mga5 qemu-img-2.4.1-5.mga5 from qemu-2.4.1-5.mga5.src.rpm
CC: (none) => thierry.vignaudAssignee: thierry.vignaud => qa-bugs
In VirtualBox, M5, KDE, 32-bit Package(s) under test: qemu qemu-img default install of qemu qemu-img [root@localhost wilcal]# urpmi qemu Package qemu-2.1.3-2.11.mga5.i586 is already installed [root@localhost wilcal]# urpmi qemu-img Package qemu-img-2.1.3-2.11.mga5.i586 is already installed create /home/wilcal/qemu_test into that copy file: Mageia-6-sta1-LiveDVD-PLASMA5-i586-DVD.iso using a terminal in /home/wilcal/qemu_test run: qemu-kvm -net user -net nic,model=virtio -cdrom file:///home/wilcal/qemu_test/Mageia-6-sta1-LiveDVD-PLASMA5-i586-DVD.iso -boot d -m 512 M6 i586 Plasma Live-DVD opens and runs. install qemu & qemu-img from updates_testing [root@localhost wilcal]# urpmi qemu Package qemu-2.4.1-5.mga5.i586 is already installed [root@localhost wilcal]# urpmi qemu-img Package qemu-img-2.4.1-5.mga5.i586 is already installed into /home/wilcal/qemu_test copy: Mageia-5-LiveDVD-KDE4-x86_64-DVD.iso using a terminal in /home/wilcal/qemu_test run: qemu-kvm -net user -net nic,model=virtio -cdrom Mageia-5-LiveDVD-KDE4-x86_64-DVD.iso -boot d -m 512 M5 x86_64 KDE Live-DVD opens and runs. [wilcal@localhost qemu_test]$ qemu-alpha usage: qemu-alpha [options] program [arguments...] Linux CPU emulator (compiled for alpha emulation) Options and associated environment variables:........
CC: (none) => wilcal.int
Whiteboard: (none) => MGA5-32-OK
In VirtualBox, M5, KDE, 64-bit Package(s) under test: qemu qemu-img default install of qemu qemu-img [root@localhost wilcal]# urpmi qemu Package qemu-2.1.3-2.11.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi qemu-img Package qemu-img-2.1.3-2.11.mga5.x86_64 is already installed create /home/wilcal/qemu_test into that copy file: Mageia-6-sta1-LiveDVD-PLASMA5-i586-DVD.iso using a terminal in /home/wilcal/qemu_test run: qemu-kvm -net user -net nic,model=virtio -cdrom file:///home/wilcal/qemu_test/Mageia-6-sta1-LiveDVD-PLASMA5-i586-DVD.iso -boot d -m 512 M6 i586 Plasma Live-DVD opens and runs. install qemu & qemu-img from updates_testing [root@localhost wilcal]# urpmi qemu Package qemu-2.4.1-5.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi qemu-img Package qemu-img-2.4.1-5.mga5.x86_64 is already installed into /home/wilcal/qemu_test copy: Mageia-5-LiveDVD-KDE4-x86_64-DVD.iso using a terminal in /home/wilcal/qemu_test run: qemu-kvm -net user -net nic,model=virtio -cdrom Mageia-5-LiveDVD-KDE4-x86_64-DVD.iso -boot d -m 512 M5 x86_64 KDE Live-DVD opens and runs. [wilcal@localhost qemu_test]$ qemu-alpha usage: qemu-alpha [options] program [arguments...] Linux CPU emulator (compiled for alpha emulation) Options and associated environment variables:........
Whiteboard: MGA5-32-OK => MGA5-32-OK MGA5-64-OK
Looks good to me. What you say David?
Sounds promising. It's preferable to test qemu on hardware and not inside of VirtualBox, but it sounds like it's working.
Also as tv said, test it with virt-manager.
In VirtualBox, M5, KDE, 32-bit Package(s) under test: qemu qemu-img virt-manager [root@localhost wilcal]# urpmi virt-manager Package virt-manager-1.1.0-7.mga5.noarch is already installed With an open client running in qemu running the virt-manager GUI nothing but error messages occured. Either I don't know how this works or virt-manager is badly documented or does not work. "Unable to connect to libvert" "Verify that the 'libvirtd' daemon is running" Details: nable to connect to libvirt. Verify that the 'libvirtd' daemon is running. Libvirt URI is: qemu:///system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 968, in _open_thread self._backend.open(self._do_creds_password) File "/usr/share/virt-manager/virtinst/connection.py", line 158, in open open_flags) File "/usr/lib/python2.7/site-packages/libvirt.py", line 105, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
In VirtualBox, M5, KDE, 64-bit Package(s) under test: qemu qemu-img virt-manager [root@localhost wilcal]# urpmi virt-manager Package virt-manager-1.1.0-7.mga5.noarch is already installed With an open client running in qemu running the virt-manager GUI nothing but error messages occured. Either I don't know how this works or virt-manager is badly documented or does not work. "Unable to connect to libvert" "Verify that the 'libvirtd' daemon is running" Details: nable to connect to libvirt. Verify that the 'libvirtd' daemon is running. Libvirt URI is: qemu:///system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 968, in _open_thread self._backend.open(self._do_creds_password) File "/usr/share/virt-manager/virtinst/connection.py", line 158, in open open_flags) File "/usr/lib/python2.7/site-packages/libvirt.py", line 105, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
1) Did you try first before the upgrade? 2) Do your CPU support EPT and did you configure VBox to present it to guests? else you cannot use qemu in a VM... (see "egrep --color '\b(ept|npt)\b' /proc/cpuinfo" )
(In reply to Thierry Vignaud from comment #50) > 1) Did you try first before the upgrade? No > 2) Do your CPU support EPT and did you configure VBox to present it to > guests? > else you cannot use qemu in a VM... > (see "egrep --color '\b(ept|npt)\b' /proc/cpuinfo" ) This is all getting quite complex and undocumented. Is this a functional test or simply ensuring that qemu works after a security update? I am not a virt-manager expert. Not even close.
This is the same as running vbox under vbox. For it to work, you'd to check the same expectations... You can also check this with VBox: - CLI: VBoxManage showvminfo <your_vm_name>egrep -i "nested" - GUI: Settings -> System/Acceleration/"Enable Nested Paging" Anyway you cannot report an error if you don't have tested the same thing before the upgrade...
Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Advisory required please David.
Advisory: ======================== Updated qemu packages fix security vulnerabilities: An out-of-bounds flaw was found in the QEMU emulator built using 'address_space_translate' to map an address to a MemoryRegionSection. The flaw could occur while doing pci_dma_read/write calls, resulting in an out-of-bounds read-write access error. A privileged user inside a guest could use this flaw to crash the guest instance (denial of service) (CVE-2015-8817, CVE-2015-8818). A NULL-pointer dereference flaw was found in the QEMU emulator built with TPR optimization for 32-bit Windows guests support. The flaw occurs when doing I/O-port write operations from the HMP interface. The 'current_cpu' value remains null because it is not called from the cpu_exec() loop, and dereferencing it results in the flaw. An attacker with access to the HMP interface could use this flaw to crash the QEMU instance (denial of service) (CVE-2016-1922). It was discovered that QEMU incorrectly handled the e1000 device. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-1981). Zuozhi Fzz discovered that QEMU incorrectly handled IDE AHCI emulation. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-2197). Zuozhi Fzz discovered that QEMU incorrectly handled USB EHCI emulation. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-2198). Zuozhi Fzz discovered that QEMU incorrectly handled USB OHCI emulation support. A privileged attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-2391). Qinghao Tang discovered that QEMU incorrectly handled USB Net emulation support. A privileged attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-2392). Qinghao Tang discovered that QEMU incorrectly handled USB Net emulation support. A privileged attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service, or possibly leak host memory bytes (CVE-2016-2538). Hongke Yang discovered that QEMU incorrectly handled NE2000 emulation support. A privileged attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-2841). Ling Liu discovered that QEMU incorrectly handled IP checksum routines. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service, or possibly leak host memory bytes (CVE-2016-2857). It was discovered that QEMU incorrectly handled the PRNG back-end support. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-2858). Wei Xiao and Qinghao Tang discovered that QEMU incorrectly handled access in the VGA module. A privileged attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service, or possibly execute arbitrary code on the host. In the default installation, when QEMU is used with libvirt, attackers would be isolated by the libvirt AppArmor profile (CVE-2016-3710). Zuozhi Fzz discovered that QEMU incorrectly handled access in the VGA module. A privileged attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service, or possibly execute arbitrary code on the host. In the default installation, when QEMU is used with libvirt, attackers would be isolated by the libvirt AppArmor profile (CVE-2016-3712). Oleksandr Bazhaniuk discovered that QEMU incorrectly handled Luminary Micro Stellaris ethernet controller emulation. A remote attacker could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-4001). Oleksandr Bazhaniuk discovered that QEMU incorrectly handled MIPSnet controller emulation. A remote attacker could use this issue to cause QEMU to crash, resulting in a denial of service (CVE-2016-4002). Donghai Zdh discovered that QEMU incorrectly handled the Task Priority Register(TPR). A privileged attacker inside the guest could use this issue to possibly leak host memory bytes (CVE-2016-4020). Du Shaobo discovered that QEMU incorrectly handled USB EHCI emulation support. A privileged attacker inside the guest could use this issue to cause QEMU to consume resources, resulting in a denial of service (CVE-2016-4037). The qemu package has been updated to version 2.4.1 and patched to fix these issues. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8817 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8818 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1922 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1981 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2197 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2198 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2391 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2392 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2538 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2841 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2857 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2858 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3710 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3712 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4001 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4002 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4020 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4037 http://wiki.qemu.org/ChangeLog/2.2 http://wiki.qemu.org/ChangeLog/2.3 http://wiki.qemu.org/ChangeLog/2.4 https://bugzilla.redhat.com/show_bug.cgi?id=1300771 https://bugzilla.redhat.com/show_bug.cgi?id=1283934 http://www.ubuntu.com/usn/usn-2891-1/ http://www.ubuntu.com/usn/usn-2974-1/
Thanks. Advisory uploaded.
Whiteboard: MGA5-32-OK MGA5-64-OK => has_procedure advisory MGA5-32-OK MGA5-64-OK
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0176.html
Status: NEW => RESOLVEDResolution: (none) => FIXED