QEMU could allow a local attacker to bypass security restrictions caused by an error in the drive_init function. By writing a header to a raw formatted disk image that specifies another image format, an attacker on a guest instance could exploit this vulnerability to read arbitrary files on the host. Reproducible: Always Steps to Reproduce: Affects QEMU 0.9.1
Thanks for the report, but please let us rate the severity of the bug ;-) lu_zero: patch can be found at: http://svn.savannah.gnu.org/viewvc/?view=rev&root=qemu&revision=4277 please bump as necessary.
Created attachment 153053 [details, diff] patch for qemu-softmmu-0.9.1 bug CVE-2008-2004 #221943
(In reply to comment #2) > Created an attachment (id=153053) [edit] > patch for qemu-softmmu-0.9.1 bug CVE-2008-2004 #221943 > don't know if this is the right procedure to propose a patch, so I posted the patch last comment (forgot to add these lines, shame on me hehehehe) so here they are, tested the patch here, and it's working. --- qemu-softmmu-0.9.1-r2.ebuild 2008-05-13 11:06:47.000000000 -0300 +++ qemu-softmmu-0.9.1-r3.ebuild 2008-05-13 11:02:47.000000000 -0300 @@ -46,6 +46,7 @@ cd "${S}" epatch "${FILESDIR}/${P}-CVE-2008-0928.patch" #212351 + epatch "${FILESDIR}/${P}-CVE-2008-2004.patch" #221943 # Alter target makefiles to accept CFLAGS set via flag-o. sed -i 's/^\(C\|OP_C\|HELPER_C\)FLAGS=/\1FLAGS+=/' \ Makefile Makefile.target tests/Makefile
Committed
Reopening it for possible stable marking and GLSA decision (No CVS access atm so I can't check wether it was committed directly to stable).
Celso: both linking the patch in the repository, or attaching it to the bug are fine. There's no need to give the diff to the ebuild though, as the additional epatch line is trivial. Thanks for your report!
I don't see the commit in the tree yet, so still [ebuild].
Sorry, my bad. Arches, please test and mark stable: =app-emulation/qemu-softmmu-0.9.1-r3 Target keywords : "amd64 ppc release x86" Already stabled : "x86" Missing keywords: "amd64 ppc release"
amd64 stable
this one is already stable for ppc
Fixed in release snapshot. This bug is finally is GLSA vote ready ;)
(In reply to comment #11) > Fixed in release snapshot. This bug is finally is GLSA vote ready ;) > Thanks Peter for the reminder ;) I vote NO.
I think we could GLSA this bug together with bug 212351. By itself, I would vote no.
OK with bug 212351
I vote yes, with bug 212351.
(In reply to comment #13) > I think we could GLSA this bug together with bug 212351. By itself, I would > vote no. (In reply to comment #14) > OK with bug 212351 > (In reply to comment #15) > I vote yes, with bug 212351. Request was already filed with... bug 212351 :)
Removed from tree.
(In reply to comment #17) > Removed from tree. Still removed from the tree. Hint: You can close.
package removed from the tree ;)
(In reply to comment #18) > (In reply to comment #17) > > Removed from tree. > > Still removed from the tree. Hint: You can close. Hint: read the vulnerability policy and stop spamming the security team. Sending us bugspam that these bugs can be closed does not release a GLSA any faster. (In reply to comment #19) > package removed from the tree ;) Read the comment at the bottom of this bug that says do not close the bug. Only the security team does that after a GLSA is released.
(In reply to Sean Amoss from comment #20) > (In reply to comment #18) > > (In reply to comment #17) > > > Removed from tree. > > > > Still removed from the tree. Hint: You can close. > > Hint: read the vulnerability policy and stop spamming the security team. > Sending us bugspam that these bugs can be closed does not release a GLSA any > faster. Not sure if a bug ignored for 5 years falls under any criteria. That being said, ping.
5 year old bug, package gone from tree -> byebye.
