Is this an --enable-sanitizers build? The virtual-device fuzzer catches 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#L310 > > I0614 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 60 02 > dd 79 > I0614 13:44:44.304204 2040 bytestream.cc:22] QEMU: ^ > I0614 13:44:44.641173 2040 bytestream.cc:22] QEMU: #0 0xaaaacbe34bd8 > in tcp_input third_party/libslirp/src/tcp_input.c:310:56 > I0614 13:44:44.641239 2040 bytestream.cc:22] QEMU: #1 0xaaaacbe22a94 > in ip6_input third_party/libslirp/src/ip6_input.c:74:9 > I0614 13:44:44.641262 2040 bytestream.cc:22] QEMU: #2 0xaaaacbe0bbbc > in slirp_input third_party/libslirp/src/slirp.c:1169:13 > I0614 13:44:44.641280 2040 bytestream.cc:22] QEMU: #3 0xaaaacbd55f6c > in net_slirp_receive third_party/qemu/net/slirp.c:136:5 > I0614 13:44:44.641296 2040 bytestream.cc:22] QEMU: #4 0xaaaacbd4e77c > in nc_sendv_compat third_party/qemu/net/net.c > I0614 13:44:44.641323 2040 bytestream.cc:22] QEMU: #5 0xaaaacbd4e77c > in qemu_deliver_packet_iov third_party/qemu/net/net.c:850:15 > I0614 13:44:44.641342 2040 bytestream.cc:22] QEMU: #6 0xaaaacbd50bfc > in qemu_net_queue_deliver_iov third_party/qemu/net/queue.c:179:11 > I0614 13:44:44.641359 2040 bytestream.cc:22] QEMU: #7 0xaaaacbd50bfc > in qemu_net_queue_send_iov third_party/qemu/net/queue.c:246:11 > I0614 13:44:44.641382 2040 bytestream.cc:22] QEMU: #8 0xaaaacbd4a88c > in qemu_sendv_packet_async third_party/qemu/net/net.c:891:12 > I0614 13:44:44.641396 2040 bytestream.cc:22] QEMU: #9 0xaaaacacb1de0 > in 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_poll third_party/qemu/util/main-loop.c:232:9 > I0614 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_loop third_party/qemu/softmmu/runstate.c:727:9 > I0614 13:44:44.641612 2040 bytestream.cc:22] QEMU: #21 > 0xaaaacadacb5c in main > > Patrick
