* [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-06 2:44 Alexander Bulekov 2020-07-07 4:52 ` [Bug 1886362] " Philippe Mathieu-Daudé ` (5 more replies) 0 siblings, 6 replies; 27+ messages in thread From: Alexander Bulekov @ 2020-07-06 2:44 UTC (permalink / raw) To: qemu-devel Public bug reported: 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 ** Affects: qemu Importance: Undecided Status: New -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1886362] Re: Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 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 ` Philippe Mathieu-Daudé 2020-07-09 15:51 ` [Bug 1886362] [NEW] " Li Qiang ` (4 subsequent siblings) 5 siblings, 0 replies; 27+ messages in thread From: Philippe Mathieu-Daudé @ 2020-07-07 4:52 UTC (permalink / raw) To: qemu-devel Running with '-trace e1000\*': e1000e_cb_pci_realize E1000E PCI realize entry e1000e_mac_set_permanent Set permanent MAC: 52:54:00:12:34:56 e1000e_cfg_support_virtio Virtio header supported: 0 e1000e_rx_set_cso RX CSO state set to 0 e1000e_cb_qdev_reset E1000E qdev reset entry e1000x_mac_indicate Indicating MAC to guest: 52:54:00:12:34:56 e1000x_rx_can_recv_disabled link_up: 1, rx_enabled 0, pci_master 0 e1000x_rx_can_recv_disabled link_up: 1, rx_enabled 0, pci_master 0 e1000e_vm_state_running VM state is running [R +0.094581] outl 0xcf8 0x80001010 [S +0.094604] OK [R +0.094632] outl 0xcfc 0xe1020000 [S +0.094654] OK [R +0.094668] outl 0xcf8 0x80001014 [S +0.094675] OK [R +0.094694] outl 0xcf8 0x80001004 [S +0.094702] OK [R +0.094712] outw 0xcfc 0x7 e1000e_rx_start_recv [S +0.096938] OK [R +0.096960] outl 0xcf8 0x800010a2 [S +0.096972] OK [R +0.096986] write 0xe102003b 0x1 0xff e1000e_core_write Write to register 0x38, 4 byte(s), value: 0xff e1000e_vlan_vet Setting VLAN ethernet type 0xFF [S +0.097019] OK [R +0.097034] write 0xe1020103 0x1e 0xffffff055c5e5c30be4511d084ffffffffffffffffffffffffffffffffff e1000e_core_write Write to register 0x100, 4 byte(s), value: 0xff e1000e_rx_set_rctl RCTL = 0xff e1000e_rx_desc_buff_sizes buffer sizes: [2048, 0, 0, 0] e1000e_rx_desc_len RX descriptor length: 16 e1000e_rx_start_recv e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x104, 4 byte(s), value: 0x5c05ffff e1000e_core_write Write to register 0x2820, 4 byte(s), value: 0xbe305c5e e1000e_irq_rdtr_fpd_not_running FPD written while RDTR was not running e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x10c, 4 byte(s), value: 0x84d01145 e1000e_core_write Write to register 0x2800, 4 byte(s), value: 0xffffffff e1000e_core_write Write to register 0x2804, 4 byte(s), value: 0xffffffff e1000e_core_write Write to register 0x2808, 4 byte(s), value: 0xffffffff e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x11c, 4 byte(s), value: 0xffffffff e1000e_core_write Write to register 0x2810, 4 byte(s), value: 0xff [S +0.097143] OK [R +0.097159] write 0xe1020420 0x4 0xffffffff e1000e_core_write Write to register 0x3800, 4 byte(s), value: 0xffffffff [S +0.097173] OK [R +0.097183] write 0xe1020424 0x4 0xffffffff e1000e_core_write Write to register 0x3804, 4 byte(s), value: 0xffffffff [S +0.097196] OK [R +0.097208] write 0xe102042b 0x1 0xff e1000e_core_write Write to register 0x3808, 4 byte(s), value: 0xff [S +0.097221] OK [R +0.097231] write 0xe1020430 0x4 0x055c5e5c e1000e_core_write Write to register 0x3810, 4 byte(s), value: 0x5c5e5c05 [S +0.097243] OK [R +0.097253] write 0x5c041 0x1 0x04 [S +0.097914] OK [R +0.097942] write 0x5c042 0x1 0x02 [S +0.097953] OK [R +0.097964] write 0x5c043 0x1 0xe1 [S +0.097972] OK [R +0.097984] write 0x5c048 0x1 0x8a [S +0.097992] OK [R +0.098003] write 0x5c04a 0x1 0x31 [S +0.098011] OK [R +0.098022] write 0x5c04b 0x1 0xff [S +0.098029] OK [R +0.098040] write 0xe1020403 0x1 0xff e1000e_core_write Write to register 0x400, 4 byte(s), value: 0xff e1000e_tx_descr 0xe1020400 : ff31008a 0 e1000e_core_read Read from register 0x400, 4 byte(s), value: 0xff e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x404, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x408, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x40c, 4 byte(s) e1000e_core_read Read from register 0x410, 4 byte(s), value: 0x602008 e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x414, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x418, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x41c, 4 byte(s) e1000e_core_read Read from register 0x3800, 4 byte(s), value: 0xfffffff0 e1000e_core_read Read from register 0x3804, 4 byte(s), value: 0xffffffff e1000e_core_read Read from register 0x3808, 4 byte(s), value: 0x80 e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x42c, 4 byte(s) e1000e_core_read Read from register 0x3810, 4 byte(s), value: 0x5c05 e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x434, 4 byte(s) e1000e_core_read Read from register 0x3818, 4 byte(s), value: 0x0 e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x43c, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x3820, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x444, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x448, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x44c, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x450, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x454, 4 byte(s) e1000e_core_read Read from register 0x458, 4 byte(s), value: 0x0 e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x45c, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x460, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x464, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x468, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x46c, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x470, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x474, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x478, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x47c, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x480, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x484, 4 byte(s) e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x488, 4 byte(s) e1000e_rx_receive_iov Received vector of 4 fragments e1000x_vlan_is_vlan_pkt Is VLAN packet: 0, ETH proto: 0x0, VET: 0xFF e1000e_rx_rss_started Starting RSS processing e1000e_rx_rss_disabled RSS is disabled e1000e_rx_rss_dispatched_to_queue Packet being dispatched to queue 0 e1000e_ring_free_space ring #0: LEN: 1048448, DH: 255, DT: 0 e1000e_rx_has_buffers ring #0: free descr: 65273, packet size 142, descr buffer size 2048 e1000e_rx_descr Next RX descriptor: ring #0, PA: 0xfe0, length: 16 e1000e_rx_null_descriptor Null RX descriptor!! e1000e_rx_descr Next RX descriptor: ring #0, PA: 0xff0, length: 16 e1000e_rx_null_descriptor Null RX descriptor!! e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x1000, length: 16 e1000e_rx_null_descriptor Null RX descriptor!! e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x1010, length: 16 e1000e_rx_null_descriptor Null RX descriptor!! [...] e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c020, length: 16 e1000e_rx_null_descriptor Null RX descriptor!! e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c030, length: 16 e1000e_rx_null_descriptor Null RX descriptor!! e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c040, length: 16 e1000e_rx_desc_buff_write buffer #0, addr: 0xe1020400, offset: 0, from: 0x631000028830, length: 14 e1000e_core_write Write to register 0x400, 4 byte(s), value: 0xff e1000e_tx_descr 0xe1020400 : ff31008a 0 e1000e_irq_rearm_timer Mitigation timer armed for register 0x3820, delay 0 ns e1000e_irq_set_cause_entry Going to set IRQ cause 0x2, ICR: 0x0 e1000e_irq_set_cause_exit Set IRQ cause 0x3, ICR: 0x3 e1000e_irq_fix_icr_asserted ICR_ASSERTED bit fixed: 0x80000003 e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x80000003, IMS: 0x0) e1000e_irq_legacy_notify IRQ line state: 0 e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x404, 4 byte(s), value: 0x0 e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x408, 4 byte(s), value: 0x0 e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x40c, 4 byte(s), value: 0x0 e1000e_rx_desc_buff_write buffer #0, addr: 0xe1020400, offset: 14, from: 0x62500024200e, length: 124 ================================================================= ==32103==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500024200e at pc 0x55cd3c40c9aa bp 0x7ffd97112bf0 sp 0x7ffd971123a0 -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 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 ` Li Qiang 2020-07-09 17:36 ` Paolo Bonzini 2020-07-21 12:14 ` [Bug 1886362] " P J P ` (3 subsequent siblings) 5 siblings, 1 reply; 27+ messages in thread From: Li Qiang @ 2020-07-09 15:51 UTC (permalink / raw) To: Bug 1886362, Paolo Bonzini, Jason Wang; +Cc: Qemu Developers Alexander Bulekov <1886362@bugs.launchpad.net> 于2020年7月6日周一 上午10:51写道: > > Public bug reported: > > 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 > This bug is interesting. We first set the e1000e BAR0 to '0xe1020000'. Then we trigger a path: e1000e_mmio_write->...e1000e_process_tx_desc->net_tx_pkt_add_raw_fragment. In the last function we allocate an io vector 'ventry->iov_base'. Then we continue: e1000e_tx_pkt_send->net_tx_pkt_send_loopback...->e1000e_nc_receive_iov--> e1000e_write_packet_to_guest->e1000e_write_to_rx_buffers. Here comes the interesting part. e1000e_write_to_rx_buffers write to the e1000e's MMIO! Not a RAM. So another round address dispatch is begin. This time we also goes to the e1000e_mmio_write->...e1000e_process_tx_desc, However this time we goes to 'net_tx_pkt_reset' so the io vector allocated in 'net_tx_pkt_add_raw_fragment' was freed. Then in 'e1000e_write_to_rx_buffers' while loop. It will access the freed io vector. Summar as this: The guest trigger a e1000e packet send and set the data's address to the e1000e's MMIO address so this trigger another MMIO write and causes this UAF. 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. Add Paolo and Jason. Thanks, Li Qiang > 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 > > ** Affects: qemu > Importance: Undecided > Status: New > > -- > 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 2020-07-09 15:51 ` [Bug 1886362] [NEW] " Li Qiang @ 2020-07-09 17:36 ` Paolo Bonzini 2020-07-10 10:37 ` Li Qiang 0 siblings, 1 reply; 27+ messages in thread From: Paolo Bonzini @ 2020-07-09 17:36 UTC (permalink / raw) To: Li Qiang, Bug 1886362, Jason Wang; +Cc: Qemu Developers 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 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. Paolo ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 2020-07-09 17:36 ` Paolo Bonzini @ 2020-07-10 10:37 ` Li Qiang 2020-07-14 8:56 ` Jason Wang 0 siblings, 1 reply; 27+ messages in thread From: Li Qiang @ 2020-07-10 10:37 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Bug 1886362, Jason Wang, Qemu Developers Paolo Bonzini <pbonzini@redhat.com> 于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. > 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? So even if we again trigger the MMIO write, then second bh will not be executed? Thanks, Li Qiang > > Paolo > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-14 8:56 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-14 8:56 UTC (permalink / raw) To: Li Qiang, Paolo Bonzini; +Cc: Bug 1886362, Qemu Developers On 2020/7/10 下午6:37, Li Qiang wrote: > Paolo Bonzini <pbonzini@redhat.com> 于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. > > >> 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. > 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 >> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-14 8:56 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-14 8:56 UTC (permalink / raw) To: qemu-devel On 2020/7/10 下午6:37, Li Qiang wrote: > Paolo Bonzini <pbonzini@redhat.com> 于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. > > >> 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. > 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-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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 2020-07-14 8:56 ` Jason Wang (?) @ 2020-07-14 10:48 ` Li Qiang 2020-07-15 8:35 ` Jason Wang -1 siblings, 1 reply; 27+ messages in thread From: Li Qiang @ 2020-07-14 10:48 UTC (permalink / raw) To: Jason Wang; +Cc: Paolo Bonzini, Bug 1886362, Qemu Developers Jason Wang <jasowang@redhat.com> 于2020年7月14日周二 下午4:56写道: > > > On 2020/7/10 下午6:37, Li Qiang wrote: > > Paolo Bonzini <pbonzini@redhat.com> 于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 use 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? > > > > > > >> 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 > >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-15 8:35 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-15 8:35 UTC (permalink / raw) To: Li Qiang; +Cc: Paolo Bonzini, Bug 1886362, Qemu Developers On 2020/7/14 下午6:48, Li Qiang wrote: > Jason Wang <jasowang@redhat.com> 于2020年7月14日周二 下午4:56写道: >> >> On 2020/7/10 下午6:37, Li Qiang wrote: >>> Paolo Bonzini <pbonzini@redhat.com> 于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 >>>> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-15 8:35 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-15 8:35 UTC (permalink / raw) To: qemu-devel On 2020/7/14 下午6:48, Li Qiang wrote: > Jason Wang <jasowang@redhat.com> 于2020年7月14日周二 下午4:56写道: >> >> On 2020/7/10 下午6:37, Li Qiang wrote: >>> Paolo Bonzini <pbonzini@redhat.com> 于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 >>>> -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 12:31 ` Peter Maydell 0 siblings, 0 replies; 27+ messages in thread From: Peter Maydell @ 2020-07-21 12:31 UTC (permalink / raw) To: Jason Wang; +Cc: Paolo Bonzini, Bug 1886362, Li Qiang, Qemu Developers 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... > For > e1000e and other networking devices we need make sure such DMA doesn't > break anything. 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... thanks -- PMM ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 12:31 ` Peter Maydell 0 siblings, 0 replies; 27+ messages in thread From: Peter Maydell @ 2020-07-21 12:31 UTC (permalink / raw) To: qemu-devel 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... > For > e1000e and other networking devices we need make sure such DMA doesn't > break anything. 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... 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 13:21 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-21 13:21 UTC (permalink / raw) To: Peter Maydell; +Cc: Paolo Bonzini, Bug 1886362, Li Qiang, Qemu Developers 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 > >> For >> e1000e and other networking devices we need make sure such DMA doesn't >> break anything. > 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 Simply git grep loopback in hw/net tells me we probably need only to audit dp8393x and rtl8139. Qiang, want to help to audit those devices? Thanks > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 13:21 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-21 13:21 UTC (permalink / raw) To: qemu-devel 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 > >> For >> e1000e and other networking devices we need make sure such DMA doesn't >> break anything. > 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 Simply git grep loopback in hw/net tells me we probably need only to audit dp8393x and rtl8139. Qiang, want to help to audit those devices? Thanks > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 13:44 ` Peter Maydell 0 siblings, 0 replies; 27+ messages in thread From: Peter Maydell @ 2020-07-21 13:44 UTC (permalink / raw) To: Jason Wang; +Cc: Paolo Bonzini, Bug 1886362, Li Qiang, Qemu Developers 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 13:44 ` Peter Maydell 0 siblings, 0 replies; 27+ messages in thread From: Peter Maydell @ 2020-07-21 13:44 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 14:37 ` Alexander Bulekov 0 siblings, 0 replies; 27+ messages in thread From: Alexander Bulekov @ 2020-07-21 14:37 UTC (permalink / raw) To: Peter Maydell Cc: Paolo Bonzini, Jason Wang, Li Qiang, Bug 1886362, Qemu Developers On 200721 1444, Peter Maydell wrote: > 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 searched around but couldn't find anything talking about this case for real hardware. I also looked at some HDL code for FPGAs that do DMA, but it seems most of the PCI DMA components are contained in proprietary IPs, though maybe I'm missing something (I've never programmed a DMA-capable FPGA). > > 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. Could this be something that we check for in the pci_dma_* functions in hw/pci/pci.h? There we still have context about the source device for the dma read/write and could, compare addr against the device's PCI BARr's. Not sure about: 1.) How to do this without the overhead of convering the addr to a MemoryRegion, which is normally done, once, at the flatview_write stage. 2.) What to do if we catch such a DMA request? Quietly drop it? 3.) Non-PCI devices. I think this still doesn't cover the even crazier case where: CPU writes to DEV_A's MMIO DEV_A writes to DEV_B's MMIO DEV_B writes to DEV_A's MMIO and neither DEV_A or DEV_B use BHs... -Alex > thanks > -- PMM > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-21 14:37 ` Alexander Bulekov 0 siblings, 0 replies; 27+ messages in thread From: Alexander Bulekov @ 2020-07-21 14:37 UTC (permalink / raw) To: qemu-devel On 200721 1444, Peter Maydell wrote: > 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 searched around but couldn't find anything talking about this case for real hardware. I also looked at some HDL code for FPGAs that do DMA, but it seems most of the PCI DMA components are contained in proprietary IPs, though maybe I'm missing something (I've never programmed a DMA-capable FPGA). > > 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. Could this be something that we check for in the pci_dma_* functions in hw/pci/pci.h? There we still have context about the source device for the dma read/write and could, compare addr against the device's PCI BARr's. Not sure about: 1.) How to do this without the overhead of convering the addr to a MemoryRegion, which is normally done, once, at the flatview_write stage. 2.) What to do if we catch such a DMA request? Quietly drop it? 3.) Non-PCI devices. I think this still doesn't cover the even crazier case where: CPU writes to DEV_A's MMIO DEV_A writes to DEV_B's MMIO DEV_B writes to DEV_A's MMIO and neither DEV_A or DEV_B use BHs... -Alex > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-22 3:25 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-22 3:25 UTC (permalink / raw) To: Peter Maydell Cc: Paolo Bonzini, Bug 1886362, Li Qiang, Qemu Developers, Michael S. Tsirkin On 2020/7/21 下午9:44, Peter Maydell wrote: > 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. Well, my understanding is: - it's not about whether or not we have an actual device that can do DMA into itself but whether it's allowed by PCI spec - it's not really matter whether or not it tries to DMA into itself. Devices could be taught to DMA into each other's RX: e1000e(1) RX DMA to e1000e(2) MMIO (RX) e1000e(2) RX DMA to e1000e(1) RX So we get re-reentrancy again. > >>> 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. Right, so about the solution, instead of refactoring DMA I wonder we can simply detect and fail the RX by device itself. Thanks > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-22 3:25 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-22 3:25 UTC (permalink / raw) To: qemu-devel On 2020/7/21 下午9:44, Peter Maydell wrote: > 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. Well, my understanding is: - it's not about whether or not we have an actual device that can do DMA into itself but whether it's allowed by PCI spec - it's not really matter whether or not it tries to DMA into itself. Devices could be taught to DMA into each other's RX: e1000e(1) RX DMA to e1000e(2) MMIO (RX) e1000e(2) RX DMA to e1000e(1) RX So we get re-reentrancy again. > >>> 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. Right, so about the solution, instead of refactoring DMA I wonder we can simply detect and fail the RX by device itself. Thanks > > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 2020-07-21 13:21 ` Jason Wang (?) (?) @ 2020-07-21 13:46 ` Li Qiang 2020-07-22 3:27 ` Jason Wang -1 siblings, 1 reply; 27+ messages in thread From: Li Qiang @ 2020-07-21 13:46 UTC (permalink / raw) To: Jason Wang; +Cc: Peter Maydell, Bug 1886362, Qemu Developers, Paolo Bonzini Jason Wang <jasowang@redhat.com> 于2020年7月21日周二 下午9:21写道: > > > 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 > > > > > >> For > >> e1000e and other networking devices we need make sure such DMA doesn't > >> break anything. > > 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 IMO I think this is not related-loopback. It happens when the guest write the MMIO address to the device's DMA-related registers. The one we see UAF occurs in loopback device because the same structure uses in re-entry. But we can't say there are no issue for non-loopback device. > > Simply git grep loopback in hw/net tells me we probably need only to > audit dp8393x and rtl8139. > > Qiang, want to help to audit those devices? No problem. Once I finish the e1000e patch I will try to audit those and also try to audit some no-loopback device re-entry issue. Thanks, Li Qiang > > Thanks > > > > > > thanks > > -- PMM > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-22 3:27 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-22 3:27 UTC (permalink / raw) To: Li Qiang; +Cc: Peter Maydell, Bug 1886362, Qemu Developers, Paolo Bonzini On 2020/7/21 下午9:46, Li Qiang wrote: > Jason Wang <jasowang@redhat.com> 于2020年7月21日周二 下午9:21写道: >> >> 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 >> >> >>>> For >>>> e1000e and other networking devices we need make sure such DMA doesn't >>>> break anything. >>> 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 > IMO I think this is not related-loopback. > > It happens when the guest write the MMIO address to the device's > DMA-related registers. > The one we see UAF occurs in loopback device because the same > structure uses in re-entry. > But we can't say there are no issue for non-loopback device. Yes. >> Simply git grep loopback in hw/net tells me we probably need only to >> audit dp8393x and rtl8139. >> >> Qiang, want to help to audit those devices? > No problem. Once I finish the e1000e patch I will try to audit those and > also try to audit some no-loopback device re-entry issue. Thanks. > > Thanks, > Li Qiang > >> Thanks >> >> >>> thanks >>> -- PMM >>> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers @ 2020-07-22 3:27 ` Jason Wang 0 siblings, 0 replies; 27+ messages in thread From: Jason Wang @ 2020-07-22 3:27 UTC (permalink / raw) To: qemu-devel On 2020/7/21 下午9:46, Li Qiang wrote: > Jason Wang <jasowang@redhat.com> 于2020年7月21日周二 下午9:21写道: >> >> 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 >> >> >>>> For >>>> e1000e and other networking devices we need make sure such DMA doesn't >>>> break anything. >>> 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 > IMO I think this is not related-loopback. > > It happens when the guest write the MMIO address to the device's > DMA-related registers. > The one we see UAF occurs in loopback device because the same > structure uses in re-entry. > But we can't say there are no issue for non-loopback device. Yes. >> Simply git grep loopback in hw/net tells me we probably need only to >> audit dp8393x and rtl8139. >> >> Qiang, want to help to audit those devices? > No problem. Once I finish the e1000e patch I will try to audit those and > also try to audit some no-loopback device re-entry issue. Thanks. > > Thanks, > Li Qiang > >> Thanks >> >> >>> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1886362] Re: Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 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-21 12:14 ` P J P 2021-05-26 14:34 ` Thomas Huth ` (2 subsequent siblings) 5 siblings, 0 replies; 27+ messages in thread From: P J P @ 2020-07-21 12:14 UTC (permalink / raw) To: qemu-devel Another reproducer: (just to record) cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc-q35-5.0 \ -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 \ -display none -nodefaults -nographic -qtest stdio outl 0xcf8 0x80000810 outl 0xcfc 0xe0000000 outl 0xcf8 0x80000804 outw 0xcfc 0x7 write 0xe0000758 0x4 0xfffff1ff write 0xe0000760 0x6 0xffffdf000000 write 0xe0000768 0x4 0x0efffff1 write 0xe0005008 0x4 0x18ffff27 write 0xe0000c 0x1 0x66 write 0xe03320 0x1 0xff write 0xe03620 0x1 0xff write 0xe00000f3 0x1 0xdf write 0xe0000100 0x6 0xdfffffdf0000 write 0xe0000110 0x5 0xdfffffdf00 write 0xe000011a 0x3 0xffffff write 0xe0000128 0x5 0x7e00ffffff write 0xe0000403 0x1 0xdf write 0xe0000420 0x4 0xdfffffdf write 0xe000042a 0x3 0xffffff write 0xe0000438 0x1 0x7e EOF -> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05709.html -- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1886362] Re: Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 2020-07-06 2:44 [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers Alexander Bulekov ` (2 preceding siblings ...) 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 5 siblings, 0 replies; 27+ messages in thread From: Thomas Huth @ 2021-05-26 14:34 UTC (permalink / raw) To: qemu-devel I can reproduce this problem with QEMU v5.0, but with the current version, it does not run into this assertion anymore. Seems like this problem got fixed in the course of time? Could you please check whether you could still reproduce this? ** Changed in: qemu Status: New => Incomplete -- 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: Incomplete 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1886362] Re: Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 2020-07-06 2:44 [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers Alexander Bulekov ` (3 preceding siblings ...) 2021-05-26 14:34 ` Thomas Huth @ 2021-06-14 23:40 ` Alexander Bulekov 2021-06-15 18:19 ` Thomas Huth 5 siblings, 0 replies; 27+ messages in thread From: Alexander Bulekov @ 2021-06-14 23:40 UTC (permalink / raw) To: qemu-devel This should have been fixed by the qemu_receive_packet/network loopback patches from a few months ago -- 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: Incomplete 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1886362] Re: Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers 2020-07-06 2:44 [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers Alexander Bulekov ` (4 preceding siblings ...) 2021-06-14 23:40 ` Alexander Bulekov @ 2021-06-15 18:19 ` Thomas Huth 5 siblings, 0 replies; 27+ messages in thread From: Thomas Huth @ 2021-06-15 18:19 UTC (permalink / raw) To: qemu-devel Ok, let's mark this as fixed. ** Changed in: qemu Status: Incomplete => Fix Released -- 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: Fix Released 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2021-06-15 18:26 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.