The virtio-blk driver in qemu-kvm did not properly validate read and write requests from the guest. A privileged guest user could use this flaw to cause heap corruption, causing the guest to crash (denial of service) or, possibly, resulting in the privileged guest user escalating their privileges on the host. Reported by: Conor Murphy Originally reported: http://www.spinics.net/lists/kvm/msg51877.html Better description from RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=698906 Patch available for upstream commit (version in tree: 0.14.50) http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=52c050236eaa4f0b5e1d160cd66dc18106445c4d
Re-rating this as C1, but I guess most users will use virtio-blk, too. @qemu: please provide an updated ebuild!
Created attachment 271513 [details] qemu-kvm-0.13.0-r3.ebuild Complete ebuild
Created attachment 271515 [details, diff] qemu-kvm-0.13.0-r3.ebuild.patch as a patch only
Created attachment 271517 [details, diff] qemu-kvm-CVE-2011-1750.patch
*ping* to qemu herd. Is there anything that prevents you from merging this security patch?
Fixed in app-emulation/qemu-kvm-0.14.1, which is now in the tree.
(In reply to comment #6) > Fixed in app-emulation/qemu-kvm-0.14.1, which is now in the tree. Great, thank you. Can we move forward to stabilize =app-emulation/qemu-kvm-0.14.1?
It appears I will be making qemu-kvm-0.14.1-r1 in the morning so we'll go with that for the stable target.
(In reply to comment #8) > It appears I will be making qemu-kvm-0.14.1-r1 in the morning so we'll go with > that for the stable target. Great, thank you. Arches, please test and mark stable: =app-emulation/qemu-kvm-0.14.1-r1 Target keywords : "amd64 x86"
amd64 ok
The new USE="spice" depends on app-emulation/spice which isn't keyworded for x86 yet! Spice itself also has another un-keyworded dep app-emulation/spice-protocol. I do not think that this spicy thing can get resolved immediately, as even the few days old spice-0.8.1 ebuild contains a dep on media-libs/celt:0.5.1 which isn't stable on x86 (the newer version celt-0.7.1 is already stable here!).
(In reply to comment #11) > The new USE="spice" depends on app-emulation/spice which isn't keyworded for > x86 yet! Spice itself also has another un-keyworded dep > app-emulation/spice-protocol. > I do not think that this spicy thing can get resolved immediately, as even the > few days old spice-0.8.1 ebuild contains a dep on media-libs/celt:0.5.1 which > isn't stable on x86 (the newer version celt-0.7.1 is already stable here!). right, i missed a unstable dep. I open new bug and add as a block. Thanks
Another unstable dep for a new use=rdb in this version would be sys-cluster/ceph which is keyworded right now only for amd64 and x86...
(In reply to comment #13) > Another unstable dep for a new use=rdb in this version would be > sys-cluster/ceph which is keyworded right now only for amd64 and x86... Yes, I already looked it, it fails to compile for me, can you confirm? ( i open a bug atm )
amd64 compiles and appears to work fine on my VM ( little irony there :) )
sorry for the noise, over zealous mouse and finger
amd64: emerged, booted fedora, blended with libvirt. All up & running. It did misfire with use=rdb which is seemingly new. ERROR: User requested feature rados block device ERROR: configure was not able to find it, I for one have not heard of it, is not a bug in any form. Up & running.
amd64: One oddity, of all flags, use flag debug draws a failed configure phase, seems tied to the above mentioned rbd flag. So use flags debug and rbd draw error. Without them, emerges and works
Right now the only failing USE flag is rbd, which is actually a new feature. I would honestly USE.mask spice and rbd for people on the stable profiles while allowing them on ~arch.
yes, the use flag debug is fixed, & with rbd put aside that gives the packages a pass on amd64. Leaving the closing of 370135 to Security team.
(In reply to comment #21) > Right now the only failing USE flag is rbd, which is actually a new feature. > > I would honestly USE.mask spice and rbd for people on the stable profiles while > allowing them on ~arch. kind of emberassing... but I don't know how to do that? Can I mask a flag only for x86 but not ~x86? How?
amd64: A problem with xen use flag, xen-tools fail to emerge. A problem with rbd use flag as well. Without those 2 flags, it passes.
(In reply to comment #23) > (In reply to comment #21) > > Right now the only failing USE flag is rbd, which is actually a new feature. > > > > I would honestly USE.mask spice and rbd for people on the stable profiles while > > allowing them on ~arch. > > kind of emberassing... but I don't know how to do that? > Can I mask a flag only for x86 but not ~x86? How? No this is not possible
(In reply to comment #25) > (In reply to comment #23) > > (In reply to comment #21) > > > Right now the only failing USE flag is rbd, which is actually a new feature. > > > > > > I would honestly USE.mask spice and rbd for people on the stable profiles while > > > allowing them on ~arch. > > > > kind of emberassing... but I don't know how to do that? > > Can I mask a flag only for x86 but not ~x86? How? > > No this is not possible spice is fixed in qemu-kvm-0.14.1-r2, so for now you can use.mask 'rbd' since I don't have a fix for that yet.
spice and rbd are both masked. Please proceed
(In reply to comment #27) > spice and rbd are both masked. Please proceed Why did you mask spice flag in use.mask in BASE profile?? Since average user cannot easily override it, I would strongly suggest using that only for stuff which doesn't work. qemu-kvm works fine with spice, as long as spice is patched. Patches for spice are already in gentoo's bugzilla. Please poke maintainers to fix broken ebuilds/stabilise and don't mask use flags in base profile. If you really want to do it, arch profile is better place for it. On the side note, I've got no idea how masking spice use flag has anything to do with CVE-2011-1750 patch (Masking rbd spice from qemu-kvm per bug #364889)
it seems that qemu-kvm (0.15.0 here) won't compile with spice useflag. because of bug https://bugs.gentoo.org/show_bug.cgi?id=378907
(In reply to comment #28) > (In reply to comment #27) > > spice and rbd are both masked. Please proceed > > Why did you mask spice flag in use.mask in BASE profile?? Since average user > cannot easily override it, I would strongly suggest using that only for stuff > which doesn't work. > > qemu-kvm works fine with spice, as long as spice is patched. Patches for spice > are already in gentoo's bugzilla. > > Please poke maintainers to fix broken ebuilds/stabilise and don't mask use > flags in base profile. If you really want to do it, arch profile is better > place for it. > > On the side note, I've got no idea how masking spice use flag has anything to > do with CVE-2011-1750 patch (Masking rbd spice from qemu-kvm per bug #364889) Robert, Doug asked me to do so because the spice dependency is not ready to go stable. Until the said patches are merged to the ebuilds and hit the stable tree we need to get rid of that dependency and fix the security bug that it is more urgent. Maintainers are aware of the situation but like I said, we can't just mask use flag on stable and keep them unmask on stable. Therefore, we need to mask them globally.
(In reply to comment #28) > (In reply to comment #27) > > spice and rbd are both masked. Please proceed > > On the side note, I've got no idea how masking spice use flag has anything to > do with CVE-2011-1750 patch (Masking rbd spice from qemu-kvm per bug #364889) Sorry I forgot to answer that. I masked them because currently the wanna-be stable qemu-kvm does not build when these use flags are enabled. Therefore they had to be masked in order to be able to mark this package stable.
qemu-kvm-0.15 build against spice-0.8.1 fine. 0.8.2 is broken. I need spice support in qemu-kvm. Is any clean way how to unmask flag?
(In reply to comment #32) > qemu-kvm-0.15 build against spice-0.8.1 fine. 0.8.2 is broken. I need spice > support in qemu-kvm. Is any clean way how to unmask flag? echo "-spice" >> /etc/portage/profile/use.mask
x86 stable I think that most of the bug dependencies here are irrelevant now. Especially I cannot reproduce any of the failures from bug #370135. Arches, I think you can just go ahead.
amd64: The
No. from 370135, rbd need consideration for being unmasked, and xen need consideration for being masked or removed. xen and qemu-kvm are not confluent with one another. xen is broken and in review currently. The package emerges fine with all other use flags. Enabling xen ropes in the xen kernel-2.6.18 and a broken stable xen package. I thought I saw an indication xen flag had been removed, but apprently not.
spice useflag mask has been lifted since spice is now stable
seems it was libvirt which had xen masked due to its ''state'. qemu-kvm warrants the same, for now
Is there any intention to release the 0.13.0-r3 ebuild? We're still using 0.13 and we'd prefer a security fix over switching to 0.14 right now.
Use the supplied patches in an overlay. @qemu: please punt the vulnerable versions or patch them.
(In reply to comment #39) > Is there any intention to release the 0.13.0-r3 ebuild? We're still using 0.13 > and we'd prefer a security fix over switching to 0.14 right now. No. Use qemu-kvm-0.14.1-r2. That's been my answer the entire time. Arch teams were CC'd to stabilize this for security.
(In reply to comment #40) > Use the supplied patches in an overlay. > > @qemu: please punt the vulnerable versions or patch them. I'd love to punt the old versions. I've asked you (craig) to follow up on these tickets to get the arch teams to stabilize the security versions since its up to the security team to manage this bug.
(In reply to comment #41) > (In reply to comment #39) > > Is there any intention to release the 0.13.0-r3 ebuild? We're still using 0.13 > > and we'd prefer a security fix over switching to 0.14 right now. > > No. Use qemu-kvm-0.14.1-r2. That's been my answer the entire time. Arch teams > were CC'd to stabilize this for security. I've dropped the blocking bug to avoid any confusion. As Doug stated on his comment, arch teams please proceed with the stabilization of qemu-kvm-0.14.1-r2.
amd64: emerges with all use flags but xen, will file. This time, xen is healthy, the flaw is a minor configure problem in the ebuild. (Previous attempts, xen package didn't get to install) Otherwise passes emerging, will look at build stuff later seeing, no rush seeing it now has a blocker
amd64 done. Thanks Ian
Filed new glsa draft.
CVE-2011-1750 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1750): Multiple heap-based buffer overflows in the virtio-blk driver (hw/virtio-blk.c) in qemu-kvm 0.14.0 allow local guest users to cause a denial of service (guest crash) and possibly gain privileges via a (1) write request to the virtio_blk_handle_write function or (2) read request to the virtio_blk_handle_read function that is not properly aligned.
This issue was resolved and addressed in GLSA 201210-04 at http://security.gentoo.org/glsa/glsa-201210-04.xml by GLSA coordinator Stefan Behte (craig).
