From: Peter Maydell <peter.maydell@linaro.org>
To: Jason Wang <jasowang@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Bug 1886362 <1886362@bugs.launchpad.net>,
Li Qiang <liq3ea@gmail.com>,
Qemu Developers <qemu-devel@nongnu.org>
Subject: Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers
Date: Tue, 21 Jul 2020 14:44:37 +0100 [thread overview]
Message-ID: <CAFEAcA8ECKgRanHLiFZMDS3fd77ASBkba2nfv+iwnjgSLWnbPw@mail.gmail.com> (raw)
In-Reply-To: <28d42c0f-99eb-a9c1-e3fc-98f11ee686ab@redhat.com>
On Tue, 21 Jul 2020 at 14:21, Jason Wang <jasowang@redhat.com> wrote:
> On 2020/7/21 下午8:31, Peter Maydell wrote:
> > On Wed, 15 Jul 2020 at 09:36, Jason Wang <jasowang@redhat.com> wrote:
> >> I think the point is to make DMA to MMIO work as real hardware.
> > I wouldn't care to give a 100% guarantee that asking a real
> > h/w device to DMA to itself didn't cause it to misbehave :-)
> > It's more likely to happen-to-work because the DMA engine bit
> > of a real h/w device is going to be decoupled somewhat from
> > the respond-to-memory-transactions-for-registers logic, but
> > it probably wasn't something the designers were actively
> > thinking about either...
> I think some device want such peer to peer transactions:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst
That's a device DMAing to another device, not DMAing to *itself*
(device-to-another-device DMA should work fine in QEMU). And only
a very few devices will ever be sensible targets of the DMA --
basically things like nvme that have a looks-like-memory area,
or special cases like doorbell registers.
> > Yeah, this is the interesting part for QEMU. How should we
> > structure devices that do DMA so that we can be sure that
> > the device emulation at least doesn't crash? We could have
> > a rule that all devices that do DMA must always postpone
> > all of that DMA to a bottom-half, but that's a lot of
> > refactoring of a lot of device code...
>
>
> It looks to me the issue happens only for device with loopback
I think in principle we have a problem for any device that
(a) has memory mapped registers and (b) does DMA reads
whose address is guest-controlled. Loopback isn't a
requirement -- if the guest programs, say, an RX descriptor
base address to point at the device's own registers, you
get exactly the same kind of unexpected-reentrancy.
thanks
-- PMM
WARNING: multiple messages have this Message-ID (diff)
From: Peter Maydell <1886362@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers
Date: Tue, 21 Jul 2020 13:44:37 -0000 [thread overview]
Message-ID: <CAFEAcA8ECKgRanHLiFZMDS3fd77ASBkba2nfv+iwnjgSLWnbPw@mail.gmail.com> (raw)
Message-ID: <20200721134437.7rdxC0-WAR8Ap2c2g7ZdzmwpQV2CgTw8zwTc4hQjzwY@z> (raw)
In-Reply-To: 28d42c0f-99eb-a9c1-e3fc-98f11ee686ab@redhat.com
On Tue, 21 Jul 2020 at 14:21, Jason Wang <jasowang@redhat.com> wrote:
> On 2020/7/21 下午8:31, Peter Maydell wrote:
> > On Wed, 15 Jul 2020 at 09:36, Jason Wang <jasowang@redhat.com> wrote:
> >> I think the point is to make DMA to MMIO work as real hardware.
> > I wouldn't care to give a 100% guarantee that asking a real
> > h/w device to DMA to itself didn't cause it to misbehave :-)
> > It's more likely to happen-to-work because the DMA engine bit
> > of a real h/w device is going to be decoupled somewhat from
> > the respond-to-memory-transactions-for-registers logic, but
> > it probably wasn't something the designers were actively
> > thinking about either...
> I think some device want such peer to peer transactions:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst
That's a device DMAing to another device, not DMAing to *itself*
(device-to-another-device DMA should work fine in QEMU). And only
a very few devices will ever be sensible targets of the DMA --
basically things like nvme that have a looks-like-memory area,
or special cases like doorbell registers.
> > Yeah, this is the interesting part for QEMU. How should we
> > structure devices that do DMA so that we can be sure that
> > the device emulation at least doesn't crash? We could have
> > a rule that all devices that do DMA must always postpone
> > all of that DMA to a bottom-half, but that's a lot of
> > refactoring of a lot of device code...
>
>
> It looks to me the issue happens only for device with loopback
I think in principle we have a problem for any device that
(a) has memory mapped registers and (b) does DMA reads
whose address is guest-controlled. Loopback isn't a
requirement -- if the guest programs, say, an RX descriptor
base address to point at the device's own registers, you
get exactly the same kind of unexpected-reentrancy.
thanks
-- PMM
--
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-sanitizers:
cat << EOF | ./i386-softmmu/qemu-system-i386 -M q35,accel=qtest \
-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 0xffffff055c5e5c30be4511d084ffffffffffffffffffffffffffffffffff
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:
==22689==ERROR: 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 [0x625000268000,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
next prev parent reply other threads:[~2020-07-21 13:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 2:44 [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers Alexander Bulekov
2020-07-07 4:52 ` [Bug 1886362] " Philippe Mathieu-Daudé
2020-07-09 15:51 ` [Bug 1886362] [NEW] " Li Qiang
2020-07-09 17:36 ` Paolo Bonzini
2020-07-10 10:37 ` Li Qiang
2020-07-14 8:56 ` Jason Wang
2020-07-14 8:56 ` Jason Wang
2020-07-14 10:48 ` Li Qiang
2020-07-15 8:35 ` Jason Wang
2020-07-15 8:35 ` Jason Wang
2020-07-21 12:31 ` Peter Maydell
2020-07-21 12:31 ` Peter Maydell
2020-07-21 13:21 ` Jason Wang
2020-07-21 13:21 ` Jason Wang
2020-07-21 13:44 ` Peter Maydell [this message]
2020-07-21 13:44 ` Peter Maydell
2020-07-21 14:37 ` Alexander Bulekov
2020-07-21 14:37 ` Alexander Bulekov
2020-07-22 3:25 ` Jason Wang
2020-07-22 3:25 ` Jason Wang
2020-07-21 13:46 ` Li Qiang
2020-07-22 3:27 ` Jason Wang
2020-07-22 3:27 ` Jason Wang
2020-07-21 12:14 ` [Bug 1886362] " P J P
2021-05-26 14:34 ` Thomas Huth
2021-06-14 23:40 ` Alexander Bulekov
2021-06-15 18:19 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA8ECKgRanHLiFZMDS3fd77ASBkba2nfv+iwnjgSLWnbPw@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=1886362@bugs.launchpad.net \
--cc=jasowang@redhat.com \
--cc=liq3ea@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.