| Summary: | app-emulation/qemu-softmmu <= 0.9.1-r1 insufficient block device address range checking (CVE-2008-0928) | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Lars Hartmann <lars> | ||||||||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||||||||
| Status: | RESOLVED OBSOLETE | ||||||||||||||
| Severity: | normal | CC: | gengor, jaervosz, lu_zero, pcmoore, rose | ||||||||||||
| Priority: | High | ||||||||||||||
| Version: | unspecified | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| URL: | http://marc.info/?l=debian-security&m=120343592917055&w=2 | ||||||||||||||
| Whiteboard: | B2 [glsa] | ||||||||||||||
| Package list: | Runtime testing required: | --- | |||||||||||||
| Bug Depends on: | 221943 | ||||||||||||||
| Bug Blocks: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Lars Hartmann
2008-03-05 07:55:38 UTC
maintainer - please provide an updated ebuild also affects Xen *** Bug 211442 has been marked as a duplicate of this bug. *** updated ebuild provided, please test Did you commit it, I can't see anything in CVS. app-emulation/qemu-softmmu qemu is just a meta ebuild. Ah, sorry, I missed that. Arches, please test and mark stable: =app-emulation/qemu-softmmu-0.9.1-r1 Target keywords : "amd64 ppc release x86" Luca, you use it on x86? I don't have GCC 3 here at the moment...so a successful ok from you would be enough for me. I don't have x86 around to test it properly =/ I should check a snapshot with the replaced dygen so the gcc-3 constraint would disappear. same for me, no gcc-3 on ppc ... luca, can you keyword this package for ppc? ;) Created attachment 145714 [details] build.log Fails here. Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-3.4.6, glibc-2.6.1-r0, 2.6.24-gentoo-r3 i686) ================================================================= System uname: 2.6.24-gentoo-r3 i686 AMD Athlon(tm) X2 Dual Core Processor BE-2400 Timestamp of tree: Mon, 10 Mar 2008 06:30:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage" USE="3dnow 3dnowext X a52 acl acpi aiglx alsa apache2 apm applet artworkextra asf audiofile avahi bash-completion beagle berkdb bidi bogofilter bootsplash branding bzip2 cairo ccache cdda cddb cdparanoia cdr cli console cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evince evo exif fam fat fbcon fdftk ffmpeg firefox flac foomaticdb fortran ftp gb gcj gdbm gif glitz gnome gpm gsf gstreamer gtk gtk2 gtkhtml hal howl iconv icq idn imagemagick imap imlib immqt-bc isdnlog java javascript jpeg jpeg2k kde ldap libnotify lirc lm_sensors mad maildir matroska mbox midi mikmod mime mmx mmxext mng mono mp3 mpeg mpeg2 mudflap mule mysql nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc objc++ objc-gc offensive ogg opengl openmp pam pango pcre pdf perl php plotutils pmu png ppds pppd prediction preview-latex print python qt3 qt3support qt4 quicktime readline reflection samba sdk session slang spell spl sse ssl svg svga t1lib tcl tcpd tetex theora threads thumbnailing tiff tk toolkit-scroll-bars totem tracker truetype truetype-fonts type1-fonts udev unicode usb userlocales vcd videos vorbis win32codecs wmf wxwindows x86 xface xft xine xml xorg xosd xpm xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon ptp2" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" LIRC_DEVICES="atiusb" USERLAND="GNU" VIDEO_CARDS="vesa fbdev fglrx" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Worked on ppc ../softmmu_template.h:260: error: unable to find a register to spill in class `GENERAL_REGS' x86 vs gcc vs qemu on register allocation. That is a gcc bug (In reply to comment #13) > ../softmmu_template.h:260: error: unable to find a register to spill in class > `GENERAL_REGS' > > x86 vs gcc vs qemu on register allocation. That is a gcc bug And now? It is unlikely that a fixed GCC 3 release will appear. My proposal, as GCC 3 is hard masked and needed: Mask qemu, too, until they fix their compiler problem in general. just use another gcc-3.4 =/ or dekeyword it for x86 qemu builds fine on the other arches. Could someone from x86 verify my failures? Luca, normally a package that has hard-masked dependencies should not go stable. qemu-softmmu builds and works apparently well enough for everybody but x86 users with the latest gcc-3.4 since the register allocation is problematic and the underlying hardware has limited registers. Seems my grep foo has left me, where is <gcc-4 hard masked? (In reply to comment #18) > Seems my grep foo has left me, where is <gcc-4 hard masked? You should have looked in my local package.mask.... Could anybody from x86 verify that it does not work? Verified:
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h: In function `op_psrlq_mmx':
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:213: error: unable to find a register to spill in class `GENERAL_REGS'
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:213: error: this is the insn:
(insn:HI 36 35 37 3 /var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:207 (parallel [
(set (reg:DI 63 [ <variable>.q ])
(lshiftrt:DI (reg:DI 63 [ <variable>.q ])
(subreg:QI (reg/v:SI 60 [ shift ]) 0)))
(clobber (scratch:SI))
(clobber (reg:CC 17 flags))
]) 309 {lshrdi3_1} (insn_list 33 (insn_list 35 (nil)))
(expr_list:REG_DEAD (reg/v:SI 60 [ shift ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (scratch:SI)
(nil)))))
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:213: confused by earlier errors, bailing out
make[1]: *** [op.o] Error 1
make[1]: Leaving directory `/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/i386-softmmu'
make: *** [subdir-i386-softmmu] Error 2
So what do we do? Drop x86 keyword at all?
(In reply to comment #9) > I should check a snapshot with the replaced dygen so the gcc-3 constraint would > disappear. This sounds more promising for the future than dropping qemu support. (In reply to comment #21) > (In reply to comment #9) > > I should check a snapshot with the replaced dygen so the gcc-3 constraint would > > disappear. > > This sounds more promising for the future than dropping qemu support. GCC 3.3.6 works. Problem: Not marked stable and I am not sure if i want to do it. People will try 3.4 when asked for GCC 3... Dropping stable x86 is also no desired option, so this snapshot seems to be the best solution. Luca, your turn again. :) I'll try to prepare something, then I'll need somebody to test it Snapshot does has the same bugs. But, please, take a look at this thread: http://lists.gnu.org/archive/html/qemu-devel/2008-03/msg00243.html I'm about to suggest solution... (In reply to comment #23) > I'll try to prepare something, then I'll need somebody to test it We are here. (In reply to comment #24) > Snapshot does has the same bugs. But, please, take a look at this thread: > > http://lists.gnu.org/archive/html/qemu-devel/2008-03/msg00243.html > > I'm about to suggest solution... Yes? I did not try the patch suggested there yet, BUT I don't have a march setting in my CFLAGS, so this is not the solution. Created attachment 146286 [details, diff]
qemu-softmmu-0.9.1-r1.patch
Well, this patch fixes the build problem with gcc-3.4 here. Although I think that forcing -march is a good idea this is a good first approximation. BTW I've tried to build with "-no-sse{,2,3} -mfpmath=387" and this didn't worked. Also for unknown reason it fails if I don't pass OS_CFLAGS="${CFLAGS}" to emake too.
Questions remain: 1. is it possible that -02 or -g redefines -march defaults and enables sse? 2. What -march=pentium-mmx enables/disables to make compilation succeed?
(In reply to comment #25) > I did not try the patch suggested there yet, BUT I don't have a march > setting in my CFLAGS, so this is not the solution. And to save your time: patches suggested there do not fix anything here. Created attachment 146291 [details, diff]
Fixing some QA things and the actual bug fix
I reworked your patch (use x86 instead of querying ${ARCH}, adjusted comment), use emake install instead of plain make and a comment that econf is not possible.
Luca, this compiles, I have still to check if it works.
Christian, as I wrote in #26 build fails if you do not pass OS_CFLAGS="${CFLAGS}" to emake. I've checked. Build fails with your patch here.
(In reply to comment #28) > Created an attachment (id=146291) [edit] > Fixing some QA things and the actual bug fix > > I reworked your patch (use x86 instead of querying ${ARCH}, adjusted comment), > use emake install instead of plain make and a comment that econf is not > possible. > > Luca, this compiles, I have still to check if it works. > It compiles also here and it works. I could successfully boot from hard disk. So the only things left are question in the bug. :) (In reply to comment #29) > Christian, as I wrote in #26 build fails if you do not pass > OS_CFLAGS="${CFLAGS}" to emake. I've checked. Build fails with your patch here. Are you sure you applied my patch? As far as I can see, the OS_CFLAGS is there. (In reply to comment #31) > Are you sure you applied my patch? As far as I can see, the OS_CFLAGS is > there. Ah, sure. I'm sorry. I've applied manually and I confused + with - :) Luca, instead of -march=pentium-mmx, -march=i486 is sufficient to avoid that error. Could you please apply the patch with that little change? Peter confirmed that it is working on his system. Created attachment 146567 [details, diff]
qemu-softmmu-0.9.1-r1.patch
Small update. Seems that qemu-softmmu builds with any -march lower than pentium-mmx. I've created IMHO better patch. The ideas I've took from gcc/config.gcc so I suppose I didn't missed anything. General idea of this patch: if user forced lower march take that, if not, use CHOST to set lowest cpu.
We are playing with gcc here, so I think it's good idea if toolchain guys review and comment our work here, before we commit anything to the tree. Thank you in advance. try to force just the march flag adding more random cflags may cause other breakage so we're clear, you're not talking about changing the gcc package, just tweaking gcc CFLAGS in the qemu ebuild (In reply to comment #35) > We are playing with gcc here, so I think it's good idea if toolchain guys > review and comment our work here, before we commit anything to the tree. Thank > you in advance. Peter, I think you applied the same patch again. Or is it just me? (In reply to comment #37) > so we're clear, you're not talking about changing the gcc package, just > tweaking gcc CFLAGS in the qemu ebuild Right- Created attachment 146640 [details, diff]
qemu-softmmu-0.9.1-r1.ebuild.patch
Yea, I should clean my /tmp more regulary ... Applying correct patch.
Fixing this security issue we are getting regression: qemu does not boot with qcow2 image files: # qemu-img create -f qcow c.img 3G Formatting 'c.img', fmt=qcow, size=3145728 kB # qemu -cdrom install-x86-minimal-2007.0-r1.iso -hda ./c.img -m 256 -boot d qemu: could not open disk image ./c.img I've checked without patch everything works. Similar issue is reported at debian: http://bugs.debian.org/470664 qcow2 - is default and recommended format... what shall we do? (In reply to comment #40) > qcow2 - is default and recommended format... what shall we do? Most simple fix -> drop stable x86 I don't really like this, but fixing QEmu must be really hard here with an outdated GCC 3.4*. Still people seem to know that they switch to GCC 3.3* if they have problems (according to Gentoo Wiki), so this problem is no regression. (In reply to comment #41) > Most simple fix -> drop stable x86 Dropping keyword does not fixe the problem. Also I see your point. > I don't really like this, but fixing QEmu must be really hard here with an > outdated GCC 3.4*. Still people seem to know that they switch to GCC 3.3* if > they have problems (according to Gentoo Wiki), so this problem is no > regression. Upstream FAQ suggests that both gcc versions are supported. Well that's said take a look at bug, comment #22: https://bugzilla.redhat.com/show_bug.cgi?id=433560 seems that there is new patch that fixes regression too. Luca, please, update ebuild with that patch and patch from comment #39, if you agree with that solution. BTW, I have not tested patch from redhat yet, but it's already works for one distribution so I suppose it should work for us too. Will test later. Hardened user came on irc today. Couldn't use gcc 3.4 because of this bug, nor gcc 3.3 due to hitting bug 166392. And of course gcc 4.x is not supported. Ok, while building with gcc-3.4 is more upstream issue, security should be fixed as much as possible so I've went ahead and commited ebuild suggested in #39 + updated security patch which avoids qcow2 regression. So I think we should re'CC ppc team and proceed stabilization... thank you, sorry for being unresponsive. x86 stable, Luca can handle PPC. stabling now in bug 221943 Removed from tree. (In reply to comment #48) > Removed from tree. Still removed from the tree. Hint: You can close. @security: 1 year follow up to the follow up ping. |
