|
From: | Thomas Huth |
Subject: | Re: misaligned-pointer-use libslirp/src/tcp_input.c |
Date: | Fri, 17 Jun 2022 12:17:00 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 |
On 16/06/2022 21.03, Alexander Bulekov wrote:
On 220616 0930, Patrick Venture wrote:On Thu, Jun 16, 2022 at 6:31 AM Alexander Bulekov <alxndr@bu.edu> wrote:Is this an --enable-sanitizers build? The virtual-device fuzzer catchesYeah - it should be reproducible with a sanitizers build from HEAD -- I can try to get a manual instance going again without automation to try and reproduce it. We're testing on v7.0.0 which is when we started seeing this, I don't think we saw it in 6.2.0.Here are a few reproducers (run with --enable-sanitizers): This one complains about misalignments in ip_header, ipasfrag, qlink, ip... cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ 512M,slots=4,maxmem=0xffff000000000000 -machine q35 -nodefaults -device \ vmxnet3,netdev=net0 -netdev user,id=net0 -object \ memory-backend-ram,id=mem1,size=10M -device \ pc-dimm,id=nv1,memdev=mem1,addr=0xba19ff00000000 -object \ memory-backend-ram,id=mem2,size=10M -device \ pc-dimm,id=nv2,memdev=mem2,addr=0xbe53e14abaa00000 -object \ memory-backend-ram,id=mem3,size=10M -device \ pc-dimm,id=nv3,memdev=mem3,addr=0xfe0000e9cae00000 -object \ memory-backend-ram,id=mem4,size=10M -device \ pc-dimm,id=nv4,memdev=mem4,addr=0xf0f0f0f00000000 -qtest stdio outl 0xcf8 0x80000810 outl 0xcfc 0xe0000000 outl 0xcf8 0x80000814 outl 0xcfc 0xe0001000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0x3e 0x1 0x02 write 0x39 0x1 0x20 write 0x29 0x1 0x10 write 0x2c 0x1 0x0f write 0x2d 0x1 0x0f write 0x2e 0x1 0x0f write 0x2f 0x1 0x0f write 0xf0f0f0f00001012 0x1 0xfe write 0xf0f0f0f00001013 0x1 0xca write 0xf0f0f0f00001014 0x1 0xe9 write 0xf0f0f0f00001017 0x1 0xfe write 0xf0f0f0f0000103a 0x1 0x01 write 0xfe0000e9cafe0009 0x1 0x40 write 0xfe0000e9cafe0019 0x1 0x40 write 0x0 0x1 0xe1 write 0x1 0x1 0xfe write 0x2 0x1 0xbe write 0x3 0x1 0xba writel 0xe0001020 0xcafe0000 write 0xfe0000e9cafe0029 0x1 0x40 write 0xfe0000e9cafe0039 0x1 0x40 write 0xfe0000e9cafe0049 0x1 0x40 write 0xfe0000e9cafe0059 0x1 0x40 write 0x1f65190b 0x1 0x08 write 0x1f65190d 0x1 0x46 write 0x1f65190e 0x1 0x03 write 0x1f651915 0x1 0x01 write 0xfe0000e9cafe0069 0x1 0x40 write 0xfe0000e9cafe0079 0x1 0x40 write 0xfe0000e9cafe0089 0x1 0x40 write 0xfe0000e9cafe0099 0x1 0x40 write 0xfe0000e9cafe009d 0x1 0x10 write 0xfe0000e9cafe00a0 0x1 0xff write 0xfe0000e9cafe00a1 0x1 0x18 write 0xfe0000e9cafe00a2 0x1 0x65 write 0xfe0000e9cafe00a3 0x1 0x1f write 0xfe0000e9cafe00a9 0x1 0x40 write 0xfe0000e9cafe00ad 0x1 0x1c write 0xe0000602 0x1 0x00 EOF This one complains about misalignments in ip6_header, ip6_hdrctl... cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ 512M,slots=1,maxmem=0xffff000000000000 -machine q35 -nodefaults -device \ vmxnet3,netdev=net0 -netdev user,id=net0 -object \ memory-backend-ram,id=mem1,size=4M -device \ pc-dimm,id=nv1,memdev=mem1,addr=0x1dd860000000000 -qtest stdio outl 0xcf8 0x80000810 outl 0xcfc 0xe0000000 outl 0xcf8 0x80000814 outl 0xcfc 0xe0001000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0x0 0x1 0xe1 write 0x1 0x1 0xfe write 0x2 0x1 0xbe write 0x3 0x1 0xba write 0x3e 0x1 0x01 write 0x39 0x1 0x01 write 0x28 0x1 0x01 write 0x29 0x1 0x01 write 0x2d 0x1 0x86 write 0x2e 0x1 0xdd write 0x2f 0x1 0x01 write 0x1dd860000000112 0x1 0x10 write 0x1dd86000000013c 0x1 0x02 writel 0xe0001020 0xcafe0000 write 0x1009 0x1 0x40 write 0x100c 0x1 0x86 write 0x100d 0x1 0xdd write 0x1011 0x1 0x10 write 0x1019 0x1 0x7e write 0x101d 0x1 0x10 write 0x4d56 0x1 0x02 write 0xe0000603 0x1 0x00 EOF
Could you please open bugs on https://gitlab.freedesktop.org/slirp/libslirp/-/issues so that this information does not get lost?
Thomas
these periodically while fuzzing network-devices. However I don't think OSS-Fuzz creates reports for them for some reason. I can create qtest reproducers, if that is useful. -Alex On 220615 0942, Patrick Venture wrote:Hey - I wanted to ask if someone else has seen this or has suggestions on how to fix it in libslirp / qemu. libslirp version: 3ad1710a96678fe79066b1469cead4058713a1d9 The blow is line:https://gitlab.freedesktop.org/slirp/libslirp/-/blob/master/src/tcp_input.c#L310I0614 13:44:44.304087 2040 bytestream.cc:22] QEMU: third_party/libslirp/src/tcp_input.c:310:56: runtime error: member access within misaligned address 0xffff9a4000f4 for type 'struct qlink', which requires 8 byte alignment I0614 13:44:44.304156 2040 bytestream.cc:22] QEMU: 0xffff9a4000f4:note:pointer points here I0614 13:44:44.304184 2040 bytestream.cc:22] QEMU: 00 00 00 00 00 00 00 02 20 02 0a 00 00 01 42 01 0a 00 02 02 42 01 0a 00 00 01 86 dd 6002dd 79 I0614 13:44:44.304204 2040 bytestream.cc:22] QEMU: ^ I0614 13:44:44.641173 2040 bytestream.cc:22] QEMU: #00xaaaacbe34bd8in tcp_input third_party/libslirp/src/tcp_input.c:310:56 I0614 13:44:44.641239 2040 bytestream.cc:22] QEMU: #10xaaaacbe22a94in ip6_input third_party/libslirp/src/ip6_input.c:74:9 I0614 13:44:44.641262 2040 bytestream.cc:22] QEMU: #20xaaaacbe0bbbcin slirp_input third_party/libslirp/src/slirp.c:1169:13 I0614 13:44:44.641280 2040 bytestream.cc:22] QEMU: #30xaaaacbd55f6cin net_slirp_receive third_party/qemu/net/slirp.c:136:5 I0614 13:44:44.641296 2040 bytestream.cc:22] QEMU: #40xaaaacbd4e77cin nc_sendv_compat third_party/qemu/net/net.c I0614 13:44:44.641323 2040 bytestream.cc:22] QEMU: #50xaaaacbd4e77cin qemu_deliver_packet_iov third_party/qemu/net/net.c:850:15 I0614 13:44:44.641342 2040 bytestream.cc:22] QEMU: #60xaaaacbd50bfcin qemu_net_queue_deliver_iov third_party/qemu/net/queue.c:179:11 I0614 13:44:44.641359 2040 bytestream.cc:22] QEMU: #70xaaaacbd50bfcin qemu_net_queue_send_iov third_party/qemu/net/queue.c:246:11 I0614 13:44:44.641382 2040 bytestream.cc:22] QEMU: #80xaaaacbd4a88cin qemu_sendv_packet_async third_party/qemu/net/net.c:891:12 I0614 13:44:44.641396 2040 bytestream.cc:22] QEMU: #90xaaaacacb1de0in virtio_net_flush_tx third_party/qemu/hw/net/virtio-net.c:2586:15 I0614 13:44:44.641416 2040 bytestream.cc:22] QEMU: #10 0xaaaacacb1580 in virtio_net_tx_bh third_party/qemu/hw/net/virtio-net.c:2703:11 I0614 13:44:44.641438 2040 bytestream.cc:22] QEMU: #11 0xaaaacc2bcf64 in aio_bh_call third_party/qemu/util/async.c:142:5 I0614 13:44:44.641463 2040 bytestream.cc:22] QEMU: #12 0xaaaacc2bcf64 in aio_bh_poll third_party/qemu/util/async.c:170:13 I0614 13:44:44.641477 2040 bytestream.cc:22] QEMU: #13 0xaaaacc2b8f70 in aio_dispatch third_party/qemu/util/aio-posix.c:420:5 I0614 13:44:44.641495 2040 bytestream.cc:22] QEMU: #14 0xaaaacc2bf120 in aio_ctx_dispatch third_party/qemu/util/async.c:312:5 I0614 13:44:44.641510 2040 bytestream.cc:22] QEMU: #15 0xaaaacc3a7690 in g_main_dispatch third_party/glib/glib/gmain.c:3417:27 I0614 13:44:44.641525 2040 bytestream.cc:22] QEMU: #16 0xaaaacc3a7690 in g_main_context_dispatch third_party/glib/glib/gmain.c:4135:7 I0614 13:44:44.641546 2040 bytestream.cc:22] QEMU: #17 0xaaaacc2de3ec in glib_pollfds_pollthird_party/qemu/util/main-loop.c:232:9I0614 13:44:44.641562 2040 bytestream.cc:22] QEMU: #18 0xaaaacc2de3ec in os_host_main_loop_wait third_party/qemu/util/main-loop.c:255:5 I0614 13:44:44.641580 2040 bytestream.cc:22] QEMU: #19 0xaaaacc2de3ec in main_loop_wait third_party/qemu/util/main-loop.c:531:11 I0614 13:44:44.641598 2040 bytestream.cc:22] QEMU: #20 0xaaaacbd82798 in qemu_main_loopthird_party/qemu/softmmu/runstate.c:727:9I0614 13:44:44.641612 2040 bytestream.cc:22] QEMU: #21 0xaaaacadacb5c in main Patrick
[Prev in Thread] | Current Thread | [Next in Thread] |