From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C701CC433E3 for ; Wed, 15 Jul 2020 08:36:11 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9636A2064C for ; Wed, 15 Jul 2020 08:36:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YP2qpxUs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9636A2064C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:39388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jvcte-0007bZ-Qx for qemu-devel@archiver.kernel.org; Wed, 15 Jul 2020 04:36:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvcsy-00073y-HR for qemu-devel@nongnu.org; Wed, 15 Jul 2020 04:35:28 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:49480 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1jvcsw-0003gz-9v for qemu-devel@nongnu.org; Wed, 15 Jul 2020 04:35:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594802125; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=siW6dxLecboADCbmWSOl2mXENIDqESrv++45U2BjXYo=; b=YP2qpxUs9SO/1n6GihIzdDhJpEtgQngswivVuZXKRag3vCtP7N3JXneLR/FJURnO0pgo+C DYIAdaAQbDqBuvYOaArvVQm4X7T3OXQ2grLMreci/pj++coFaBX4WMN4jYxFESGFu0XeQk y18K2ZCHtlJdHsw2Yrm4r0iMTw0b6UM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-350-ZKjJClWzNPKP--hnDae67w-1; Wed, 15 Jul 2020 04:35:18 -0400 X-MC-Unique: ZKjJClWzNPKP--hnDae67w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 16AC419200C0; Wed, 15 Jul 2020 08:35:17 +0000 (UTC) Received: from [10.72.13.230] (ovpn-13-230.pek2.redhat.com [10.72.13.230]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9AF9D78541; Wed, 15 Jul 2020 08:35:11 +0000 (UTC) Subject: Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers To: Li Qiang References: <159400349818.1851.7243060688419202620.malonedeb@wampee.canonical.com> <2cbdf822-c74c-1af9-e5e6-7dd71412201e@redhat.com> From: Jason Wang Message-ID: Date: Wed, 15 Jul 2020 16:35:09 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=205.139.110.120; envelope-from=jasowang@redhat.com; helo=us-smtp-1.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/15 02:37:05 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -40 X-Spam_score: -4.1 X-Spam_bar: ---- X-Spam_report: (-4.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Bug 1886362 <1886362@bugs.launchpad.net>, Qemu Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 2020/7/14 下午6:48, Li Qiang wrote: > Jason Wang 于2020年7月14日周二 下午4:56写道： >> >> On 2020/7/10 下午6:37, Li Qiang wrote: >>> Paolo Bonzini 于2020年7月10日周五 上午1:36写道： >>>> On 09/07/20 17:51, Li Qiang wrote: >>>>> Maybe we should check whether the address is a RAM address in 'dma_memory_rw'? >>>>> But it is a hot path. I'm not sure it is right. Hope more discussion. >>>> Half of the purpose of dma-helpers.c (as opposed to address_space_* >>>> functions in exec.c) is exactly to support writes to MMIO. This is >>> Hi Paolo, >>> >>> Could you please explain more about this(to support writes to MMIO). >>> I can just see the dma helpers with sg DMA, not related with MMIO. >> >> Please refer doc/devel/memory.rst. >> >> The motivation of memory API is to allow support modeling different >> memory regions. DMA to MMIO is allowed in hardware so Qemu should >> emulate this behaviour. >> > I just read the code again. > So the dma_blk_io is used for some device that will need DMA to > MMIO(may be related with > device spec). But for most of the devices(networking card for > example) there is no need this DMA to MMIO. > So we just ksuse dma_memory_rw. Is this understanding right? > > Then another question. > Though the dma helpers uses a bouncing buffer, it finally write to the > device addressspace in 'address_space_unmap'. > Is there any posibility that we can again write to the MMIO like this issue? I think the point is to make DMA to MMIO work as real hardware. For e1000e and other networking devices we need make sure such DMA doesn't break anything. Thanks > > >>> >>>> especially true of dma_blk_io, which takes care of doing the DMA via a >>>> bounce buffer, possibly in multiple steps and even blocking due to >>>> cpu_register_map_client. >>>> >>>> For dma_memory_rw this is not needed, so it only needs to handle >>>> QEMUSGList, but I think the design should be the same. >>>> >>>> However, this is indeed a nightmare for re-entrancy. The easiest >>>> solution is to delay processing of descriptors to a bottom half whenever >>>> MMIO is doing something complicated. This is also better for latency >>>> because it will free the vCPU thread more quickly and leave the work to >>>> the I/O thread. >>> Do you mean we define a per-e1000e bottom half. And in the MMIO write >>> or packet send >>> trigger this bh? >> >> Probably a TX bh. >> > I will try to write this tx bh to strength my understanding in this part. > Maybe reference the virtio-net implementation I think. > > > > Thanks, > Li Qiang > >>> So even if we again trigger the MMIO write, then >>> second bh will not be executed? >> >> Bh is serialized so no re-entrancy issue. >> >> Thanks >> >> >>> >>> Thanks, >>> Li Qiang >>> >>>> Paolo >>>> From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9116C433EA for ; Wed, 15 Jul 2020 08:41:53 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9E08620657 for ; Wed, 15 Jul 2020 08:41:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E08620657 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:42420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jvczA-0000oh-Va for qemu-devel@archiver.kernel.org; Wed, 15 Jul 2020 04:41:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvcyH-0000HV-OT for qemu-devel@nongnu.org; Wed, 15 Jul 2020 04:40:57 -0400 Received: from indium.canonical.com ([91.189.90.7]:38308) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jvcyF-0006LC-4A for qemu-devel@nongnu.org; Wed, 15 Jul 2020 04:40:57 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1jvcyC-0004Sk-JN for ; Wed, 15 Jul 2020 08:40:52 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 588462E80F1 for ; Wed, 15 Jul 2020 08:40:52 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2020 08:35:09 -0000 From: Jason Wang <1886362@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: a1xndr jasowang philmd X-Launchpad-Bug-Reporter: Alexander Bulekov (a1xndr) X-Launchpad-Bug-Modifier: Jason Wang (jasowang) References: <159400349818.1851.7243060688419202620.malonedeb@wampee.canonical.com> Message-ID: Subject: Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="4809fcb62f445aaa3ae919f7f6c3cc7d156ea57a"; Instance="production-secrets-lazr.conf" X-Launchpad-Hash: 82e252e353502f9cf1ca28892e6b1c14adc64ab1 Received-SPF: none client-ip=91.189.90.7; envelope-from=bounces@canonical.com; helo=indium.canonical.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/15 02:50:56 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -58 X-Spam_score: -5.9 X-Spam_bar: ----- X-Spam_report: (-5.9 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1886362 <1886362@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20200715083509._GDQzbdpnZZvEXHGr0Qapat06Yz0pAL3xErE1VKLsfc@z> On 2020/7/14 =E4=B8=8B=E5=8D=886:48, Li Qiang wrote: > Jason Wang =E4=BA=8E2020=E5=B9=B47=E6=9C=8814=E6=97= =A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=884:56=E5=86=99=E9=81=93=EF=BC=9A >> >> On 2020/7/10 =E4=B8=8B=E5=8D=886:37, Li Qiang wrote: >>> Paolo Bonzini =E4=BA=8E2020=E5=B9=B47=E6=9C=8810= =E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8A=E5=8D=881:36=E5=86=99=E9=81=93=EF=BC= =9A >>>> On 09/07/20 17:51, Li Qiang wrote: >>>>> Maybe we should check whether the address is a RAM address in 'dma_me= mory_rw'? >>>>> But it is a hot path. I'm not sure it is right. Hope more discussion. >>>> Half of the purpose of dma-helpers.c (as opposed to address_space_* >>>> functions in exec.c) is exactly to support writes to MMIO. This is >>> Hi Paolo, >>> >>> Could you please explain more about this(to support writes to MMIO). >>> I can just see the dma helpers with sg DMA, not related with MMIO. >> >> Please refer doc/devel/memory.rst. >> >> The motivation of memory API is to allow support modeling different >> memory regions. DMA to MMIO is allowed in hardware so Qemu should >> emulate this behaviour. >> > I just read the code again. > So the dma_blk_io is used for some device that will need DMA to > MMIO(may be related with > device spec). But for most of the devices(networking card for > example) there is no need this DMA to MMIO. > So we just ksuse dma_memory_rw. Is this understanding right? > > Then another question. > Though the dma helpers uses a bouncing buffer, it finally write to the > device addressspace in 'address_space_unmap'. > Is there any posibility that we can again write to the MMIO like this iss= ue? I think the point is to make DMA to MMIO work as real hardware. For = e1000e and other networking devices we need make sure such DMA doesn't = break anything. Thanks > > >>> >>>> especially true of dma_blk_io, which takes care of doing the DMA via a >>>> bounce buffer, possibly in multiple steps and even blocking due to >>>> cpu_register_map_client. >>>> >>>> For dma_memory_rw this is not needed, so it only needs to handle >>>> QEMUSGList, but I think the design should be the same. >>>> >>>> However, this is indeed a nightmare for re-entrancy. The easiest >>>> solution is to delay processing of descriptors to a bottom half whenev= er >>>> MMIO is doing something complicated. This is also better for latency >>>> because it will free the vCPU thread more quickly and leave the work to >>>> the I/O thread. >>> Do you mean we define a per-e1000e bottom half. And in the MMIO write >>> or packet send >>> trigger this bh? >> >> Probably a TX bh. >> > I will try to write this tx bh to strength my understanding in this part. > Maybe reference the virtio-net implementation I think. > > > > Thanks, > Li Qiang > >>> So even if we again trigger the MMIO write, then >>> second bh will not be executed? >> >> Bh is serialized so no re-entrancy issue. >> >> Thanks >> >> >>> >>> Thanks, >>> Li Qiang >>> >>>> Paolo >>>> -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886362 Title: Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers Status in QEMU: New Bug description: Hello, This reproducer causes a heap-use-after free. QEMU Built with --enable-sa= nitizers: cat << EOF | ./i386-softmmu/qemu-system-i386 -M q35,accel=3Dqtest \ -qtest stdio -nographic -monitor none -serial none outl 0xcf8 0x80001010 outl 0xcfc 0xe1020000 outl 0xcf8 0x80001014 outl 0xcf8 0x80001004 outw 0xcfc 0x7 outl 0xcf8 0x800010a2 write 0xe102003b 0x1 0xff write 0xe1020103 0x1e 0xffffff055c5e5c30be4511d084fffffffffffffffffffffff= fffffffffff write 0xe1020420 0x4 0xffffffff write 0xe1020424 0x4 0xffffffff write 0xe102042b 0x1 0xff write 0xe1020430 0x4 0x055c5e5c write 0x5c041 0x1 0x04 write 0x5c042 0x1 0x02 write 0x5c043 0x1 0xe1 write 0x5c048 0x1 0x8a write 0x5c04a 0x1 0x31 write 0x5c04b 0x1 0xff write 0xe1020403 0x1 0xff EOF The Output: =3D=3D22689=3D=3DERROR: AddressSanitizer: heap-use-after-free on address = 0x62500026800e at pc 0x55b93bb18bfa bp 0x7fffdbe844f0 sp 0x7fffdbe83cb8 READ of size 2 at 0x62500026800e thread T0 #0 in __asan_memcpy (/build/i386-softmmu/qemu-system-i386+) #1 in lduw_he_p /include/qemu/bswap.h:332:5 #2 in ldn_he_p /include/qemu/bswap.h:550:1 #3 in flatview_write_continue /exec.c:3145:19 #4 in flatview_write /exec.c:3186:14 #5 in address_space_write /exec.c:3280:18 #6 in address_space_rw /exec.c:3290:16 #7 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 #8 in dma_memory_rw /include/sysemu/dma.h:113:12 #9 in pci_dma_rw /include/hw/pci/pci.h:789:5 #10 in pci_dma_write /include/hw/pci/pci.h:802:12 #11 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 #12 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 #13 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 #14 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 #15 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 #16 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 #17 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 #18 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 #19 in e1000e_process_tx_desc /hw/net/e1000e_core.c:743:17 #20 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 #21 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 #22 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 #23 in e1000e_mmio_write /hw/net/e1000e.c:109:5 #24 in memory_region_write_accessor /memory.c:483:5 #25 in access_with_adjusted_size /memory.c:544:18 #26 in memory_region_dispatch_write /memory.c:1476:16 #27 in flatview_write_continue /exec.c:3146:23 #28 in flatview_write /exec.c:3186:14 #29 in address_space_write /exec.c:3280:18 #30 in qtest_process_command /qtest.c:567:9 #31 in qtest_process_inbuf /qtest.c:710:9 #32 in qtest_read /qtest.c:722:5 #33 in qemu_chr_be_write_impl /chardev/char.c:188:9 #34 in qemu_chr_be_write /chardev/char.c:200:9 #35 in fd_chr_read /chardev/char-fd.c:68:9 #36 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #37 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.= 0.so.0+) #38 in glib_pollfds_poll /util/main-loop.c:219:9 #39 in os_host_main_loop_wait /util/main-loop.c:242:5 #40 in main_loop_wait /util/main-loop.c:518:11 #41 in qemu_main_loop /softmmu/vl.c:1664:9 #42 in main /softmmu/main.c:52:5 #43 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+) #44 in _start (/build/i386-softmmu/qemu-system-i386+) 0x62500026800e is located 14 bytes inside of 138-byte region [0x625000268= 000,0x62500026808a) freed by thread T0 here: #0 in free (/build/i386-softmmu/qemu-system-i386+) #1 in qemu_vfree /util/oslib-posix.c:238:5 #2 in address_space_unmap /exec.c:3616:5 #3 in dma_memory_unmap /include/sysemu/dma.h:148:5 #4 in pci_dma_unmap /include/hw/pci/pci.h:839:5 #5 in net_tx_pkt_reset /hw/net/net_tx_pkt.c:453:9 #6 in e1000e_process_tx_desc /hw/net/e1000e_core.c:749:9 #7 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 #8 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 #9 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 #10 in e1000e_mmio_write /hw/net/e1000e.c:109:5 #11 in memory_region_write_accessor /memory.c:483:5 #12 in access_with_adjusted_size /memory.c:544:18 #13 in memory_region_dispatch_write /memory.c:1476:16 #14 in flatview_write_continue /exec.c:3146:23 #15 in flatview_write /exec.c:3186:14 #16 in address_space_write /exec.c:3280:18 #17 in address_space_rw /exec.c:3290:16 #18 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 #19 in dma_memory_rw /include/sysemu/dma.h:113:12 #20 in pci_dma_rw /include/hw/pci/pci.h:789:5 #21 in pci_dma_write /include/hw/pci/pci.h:802:12 #22 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 #23 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 #24 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 #25 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 #26 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 #27 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 #28 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 #29 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 previously allocated by thread T0 here: #0 in posix_memalign (/build/i386-softmmu/qemu-system-i386+) #1 in qemu_try_memalign /util/oslib-posix.c:198:11 #2 in qemu_memalign /util/oslib-posix.c:214:27 #3 in address_space_map /exec.c:3558:25 #4 in dma_memory_map /include/sysemu/dma.h:138:9 #5 in pci_dma_map /include/hw/pci/pci.h:832:11 #6 in net_tx_pkt_add_raw_fragment /hw/net/net_tx_pkt.c:391:24 #7 in e1000e_process_tx_desc /hw/net/e1000e_core.c:731:14 #8 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 #9 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 #10 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 #11 in e1000e_mmio_write /hw/net/e1000e.c:109:5 #12 in memory_region_write_accessor /memory.c:483:5 #13 in access_with_adjusted_size /memory.c:544:18 #14 in memory_region_dispatch_write /memory.c:1476:16 #15 in flatview_write_continue /exec.c:3146:23 #16 in flatview_write /exec.c:3186:14 #17 in address_space_write /exec.c:3280:18 #18 in qtest_process_command /qtest.c:567:9 #19 in qtest_process_inbuf /qtest.c:710:9 #20 in qtest_read /qtest.c:722:5 #21 in qemu_chr_be_write_impl /chardev/char.c:188:9 #22 in qemu_chr_be_write /chardev/char.c:200:9 #23 in fd_chr_read /chardev/char-fd.c:68:9 #24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #25 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.= 0.so.0+) -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886362/+subscriptions