From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQRUv-0002UV-4r for qemu-devel@nongnu.org; Thu, 21 Jul 2016 23:51:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQRUq-0000aD-9I for qemu-devel@nongnu.org; Thu, 21 Jul 2016 23:51:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQRUq-0000Zu-13 for qemu-devel@nongnu.org; Thu, 21 Jul 2016 23:51:32 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 49F8BC04D291 for ; Fri, 22 Jul 2016 03:51:31 +0000 (UTC) Date: Fri, 22 Jul 2016 06:51:27 +0300 From: "Michael S. Tsirkin" Message-ID: <20160722065055-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] =?utf-8?b?W2xpcWlhbmc2LXNAMzYwLmNuOiDnrZTlpI06IEhv?= =?utf-8?q?st_memory_leakage__in_QEMU__xhci_device_emulation=5D?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, kraxel@redhat.com ----- Forwarded message from =E6=9D=8E=E5=BC=BA ----- Date: Fri, 22 Jul 2016 03:48:38 +0000 From: =E6=9D=8E=E5=BC=BA To: "Michael S. Tsirkin" Subject: =E7=AD=94=E5=A4=8D: Host memory leakage in QEMU xhci device em= ulation Message-ID: <143C0AFC63FC204CB0C55BB88F3A8ABB0181D7F7@EX02.corp.qihoo.net= > In-Reply-To: <20160722063935-mutt-send-email-mst@kernel.org> Right, a user can hotplug a lot of devices. It is a bug not a security issue. Just publish it. > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Michael S. Tsirkin [mailto:mst@redhat.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B47=E6=9C=8822=E6=97=A5= 11:42 > =E6=94=B6=E4=BB=B6=E4=BA=BA: =E6=9D=8E=E5=BC=BA > =E6=8A=84=E9=80=81: pmatouse@redhat.com; sstabellini@kernel.org; secale= rt@redhat.com; > mdroth@linux.vnet.ibm.com > =E4=B8=BB=E9=A2=98: Re: Host memory leakage in QEMU xhci device emulati= on >=20 > On Fri, Jul 22, 2016 at 02:42:56AM +0000, =E6=9D=8E=E5=BC=BA wrote: > > Hi, > > > > > > > > I found a host memory leakage issue in QEMU hcd-xhci device emulation= . > > > > > > > > DESCRIPTION > > > > _____ > > > > > > > > In usb_xhci_realize() function, it calls msix_init() which requires > > memory malloc. In usb_xhci_exit(), it doesn't call the corresponding > > function > > msix_uninit() to free the memory. > > > > This will cause host memory leakage if a malicious hotplug and unplug > > the xhci device. >=20 > Thanks for the resport. >=20 > I would say whoever can hotplug devices can just hotplug a hoge number = of > these until you run out of memory. > So I don't think it's a security vulnerability, but we should fix it. >=20 > Do you agree? If yes we can publish this on the qemu mailing list. >=20 >=20 > > > > > > code from hw/usb/hcd-xhci.c > > > > static void usb_xhci_realize(struct PCIDevice *dev, Error **errp) > > > > { > > > > int i, ret; > > > > > > > > if (xhci_get_flag(xhci, XHCI_FLAG_USE_MSI_X)) { > > > > msix_init(dev, xhci->numintrs, > > > > &xhci->mem, 0, OFF_MSIX_TABLE, > > > > &xhci->mem, 0, OFF_MSIX_PBA, > > > > 0x90); > > > > } > > > > } > > > > > > > > static void usb_xhci_exit(PCIDevice *dev) > > > > { > > > > int i; > > > > XHCIState *xhci =3D XHCI(dev); > > > > > > > > trace_usb_xhci_exit(); > > > > > > > > for (i =3D 0; i < xhci->numslots; i++) { > > > > xhci_disable_slot(xhci, i + 1); > > > > } > > > > > > > > if (xhci->mfwrap_timer) { > > > > timer_del(xhci->mfwrap_timer); > > > > timer_free(xhci->mfwrap_timer); > > > > xhci->mfwrap_timer =3D NULL; > > > > } > > > > > > > > /* destroy msix memory region *///here just destroy the memory > > region, doesn=E2=80=99t free the msix memory > > > > if (dev->msix_table && dev->msix_pba > > > > && dev->msix_entry_used) { > > > > memory_region_del_subregion(&xhci->mem, > > &dev->msix_table_mmio); > > > > memory_region_del_subregion(&xhci->mem, > &dev->msix_pba_mmio); > > > > } > > > > > > > > usb_bus_release(&xhci->bus); > > > > } > > > > > > > > DEBUG AND TEST INFO > > > > _____ > > > > > > > > Breakpoint 1, usb_xhci_realize (dev=3D0x5555592e7c20, > > errp=3D0x7fffffffc5f8) at hw/ > > usb/hcd-xhci.c:3652 > > > > 3652 msix_init(dev, xhci->numintrs, > > > > (gdb) p dev->msix_table > > > > $1 =3D (uint8_t *) 0x0 > > > > (gdb) p dev->msix_pba > > > > $2 =3D (uint8_t *) 0x0 > > > > (gdb) p dev->msix_entry_used > > > > $3 =3D (unsigned int *) 0x0 > > > > (gdb) n > > > > [Thread 0x7fffe72f7700 (LWP 49433) exited] > > > > 3657 } > > > > (gdb) p dev->msix_table > > > > $4 =3D (uint8_t *) 0x55555823a480 "" > > > > (gdb) p dev->msix_pba > > > > $5 =3D (uint8_t *) 0x55555823a590 "" > > > > (gdb) p dev->msix_entry_used > > > > $6 =3D (unsigned int *) 0x55555823a5b0 > > > > (gdb) c > > > > Continuing. > > > > > > > > Program received signal SIGPIPE, Broken pipe. > > > > 0x00007ffff69ed78d in sendmsg () at > > ../sysdeps/unix/syscall-template.S:81 > > > > 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) > > > > (gdb) i b > > > > Num Type Disp Enb Address What > > > > 1 breakpoint keep y 0x00005555559c6a68 in > usb_xhci_realize at hw/ > > usb/hcd-xhci.c:3652 > > > > breakpoint already hit 1 time > > > > 2 breakpoint keep y 0x00005555559c6c5e in usb_xhci_exit > at hw/usb/ > > hcd-xhci.c:3686 > > > > (gdb) d 1 > > > > (gdb) c > > > > Continuing. > > > > [New Thread 0x7fffe72f7700 (LWP 49451)] > > > > [Switching to Thread 0x7fffe5a04700 (LWP 49408)] > > > > > > > > Breakpoint 2, usb_xhci_exit (dev=3D0x5555592e7c20) at > > hw/usb/hcd-xhci.c:3687 > > > > 3687 if (dev->msix_table && dev->msix_pba > > > > (gdb) p dev->msix_table > > > > $7 =3D (uint8_t *) 0x55555823a480 "\f\020\340\376" > > > > (gdb) p dev->msix_pba > > > > $8 =3D (uint8_t *) 0x55555823a590 "" > > > > (gdb) p dev->msix_entry_used > > > > $9 =3D (unsigned int *) 0x55555823a5b0 > > > > (gdb) n > > > > 3688 && dev->msix_entry_used) { > > > > (gdb) n > > > > 3689 memory_region_del_subregion(&xhci->mem, > &dev-> > > msix_table_mmio); > > > > (gdb) awatch *(int*)0x55555823a480 // this three > breakpoint never > > triggered > > > > Hardware access (read/write) watchpoint 3: *(int*)0x55555823a480 > > > > (gdb) awatch *(int*)0x55555823a590 > > > > Hardware access (read/write) watchpoint 4: *(int*)0x55555823a590 > > > > (gdb) awatch *(int*)0x55555823a5b0 > > > > Hardware access (read/write) watchpoint 5: *(int*)0x55555823a5b0 > > > > (gdb) c > > > > Continuing. > > > > [Thread 0x7fffe72f7700 (LWP 49451) exited] > > > > [New Thread 0x7fffe72f7700 (LWP 49468)] > > > > > > > > > > > > I use a script modified from https://gist.github.com/sibiaoluo/979883= 2 > > to send qmp commands. > > > > The script is in attachment. We can see the memory usage is raising. > > > > > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM > TIME+ > > COMMAND > > > > 48833 root 20 0 2735700 2.057g 5152 R 149.0 70.3 34:42.56 > > qemu-system-x86 > > > > > > > > REPRODUCE > > > > _____ > > > > > > > > command used:gdb --args ./qemu-system-x86_64 -m 2048 -hda > > /root/centos6.img -enable-kvm -qmp unix:/tmp/qmp-socket,server,nowait > > > > > > > > Then run the attachment script, it will show the qemu process memory > > usage is raising. > > > > > > > > TEST ENVIRONMENT > > > > _____ > > > > > > > > CentOS 7 x64 > > > > http://wiki.qemu-project.org/download/qemu-2.6.0.tar.bz2 > > > > > > > > Thanks, > > > > > > > > Li Qiang of the Cloud Security Team, Qihoo 360 Inc. > > >=20 ----- End forwarded message -----