* misaligned-pointer-use libslirp/src/tcp_input.c @ 2022-06-15 16:42 Patrick Venture 2022-06-16 13:30 ` Alexander Bulekov 0 siblings, 1 reply; 9+ messages in thread From: Patrick Venture @ 2022-06-15 16:42 UTC (permalink / raw) To: QEMU Developers; +Cc: Peter Foley [-- Attachment #1: Type: text/plain, Size: 3753 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 11156 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-15 16:42 misaligned-pointer-use libslirp/src/tcp_input.c Patrick Venture @ 2022-06-16 13:30 ` Alexander Bulekov 2022-06-16 16:30 ` Patrick Venture 0 siblings, 1 reply; 9+ messages in thread From: Alexander Bulekov @ 2022-06-16 13:30 UTC (permalink / raw) To: Patrick Venture; +Cc: QEMU Developers, Peter Foley 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-16 13:30 ` Alexander Bulekov @ 2022-06-16 16:30 ` Patrick Venture 2022-06-16 19:03 ` Alexander Bulekov 0 siblings, 1 reply; 9+ messages in thread From: Patrick Venture @ 2022-06-16 16:30 UTC (permalink / raw) To: Alexander Bulekov; +Cc: QEMU Developers, Peter Foley [-- Attachment #1: Type: text/plain, Size: 4691 bytes --] 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 catches > Yeah - 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. > 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 > [-- Attachment #2: Type: text/html, Size: 5835 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-16 16:30 ` Patrick Venture @ 2022-06-16 19:03 ` Alexander Bulekov 2022-06-17 10:17 ` Thomas Huth 0 siblings, 1 reply; 9+ messages in thread From: Alexander Bulekov @ 2022-06-16 19:03 UTC (permalink / raw) To: Patrick Venture; +Cc: QEMU Developers, Peter Foley 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 catches > > > > Yeah - 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 -Alex > > > > 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 > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-16 19:03 ` Alexander Bulekov @ 2022-06-17 10:17 ` Thomas Huth 2022-06-17 14:37 ` Alexander Bulekov 0 siblings, 1 reply; 9+ messages in thread From: Thomas Huth @ 2022-06-17 10:17 UTC (permalink / raw) To: Alexander Bulekov, Patrick Venture Cc: QEMU Developers, Peter Foley, Marc-André Lureau, Samuel Thibault 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 catches >>> >> >> Yeah - 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#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 >>> > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-17 10:17 ` Thomas Huth @ 2022-06-17 14:37 ` Alexander Bulekov 2022-06-21 16:47 ` Patrick Venture 0 siblings, 1 reply; 9+ messages in thread From: Alexander Bulekov @ 2022-06-17 14:37 UTC (permalink / raw) To: Thomas Huth Cc: Patrick Venture, QEMU Developers, Peter Foley, Marc-André Lureau, Samuel Thibault On 220617 1217, Thomas Huth wrote: > 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 catches > > > > > > > > > > Yeah - 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? Done: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/62 https://gitlab.freedesktop.org/slirp/libslirp/-/issues/63 -Alex > > 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#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 > > > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-17 14:37 ` Alexander Bulekov @ 2022-06-21 16:47 ` Patrick Venture 2022-06-21 17:17 ` Peter Foley 0 siblings, 1 reply; 9+ messages in thread From: Patrick Venture @ 2022-06-21 16:47 UTC (permalink / raw) To: Alexander Bulekov Cc: Thomas Huth, QEMU Developers, Peter Foley, Marc-André Lureau, Samuel Thibault [-- Attachment #1: Type: text/plain, Size: 9663 bytes --] On Fri, Jun 17, 2022 at 7:37 AM Alexander Bulekov <alxndr@bu.edu> wrote: > On 220617 1217, Thomas Huth wrote: > > 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 > catches > > > > > > > > > > > > > Yeah - 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? > > Done: > https://gitlab.freedesktop.org/slirp/libslirp/-/issues/62 > https://gitlab.freedesktop.org/slirp/libslirp/-/issues/63 Thank you! > > > -Alex > > > > > 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#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 > > > > > > > > > > > [-- Attachment #2: Type: text/html, Size: 13422 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-21 16:47 ` Patrick Venture @ 2022-06-21 17:17 ` Peter Foley 2022-06-21 19:33 ` Patrick Venture 0 siblings, 1 reply; 9+ messages in thread From: Peter Foley @ 2022-06-21 17:17 UTC (permalink / raw) To: Patrick Venture Cc: Alexander Bulekov, Thomas Huth, QEMU Developers, Marc-André Lureau, Samuel Thibault [-- Attachment #1: Type: text/plain, Size: 10298 bytes --] The upstream fixes in https://gitlab.freedesktop.org/slirp/libslirp/-/commit/6489ebbc691f5d97221ad154d570a231e30fb369 and https://gitlab.freedesktop.org/slirp/libslirp/-/commit/cc20d9ac578aec5502dcb26557765d3e9433cb26 resolved the failure we were seeing in our internal test-case. Thanks! On Tue, Jun 21, 2022 at 12:47 PM Patrick Venture <venture@google.com> wrote: > > > On Fri, Jun 17, 2022 at 7:37 AM Alexander Bulekov <alxndr@bu.edu> wrote: > >> On 220617 1217, Thomas Huth wrote: >> > 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 >> catches >> > > > > >> > > > >> > > > Yeah - 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? >> >> Done: >> https://gitlab.freedesktop.org/slirp/libslirp/-/issues/62 >> https://gitlab.freedesktop.org/slirp/libslirp/-/issues/63 > > > Thank you! > >> >> >> -Alex >> >> > >> > 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#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 >> > > > > >> > > >> > >> > [-- Attachment #2: Type: text/html, Size: 14316 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: misaligned-pointer-use libslirp/src/tcp_input.c 2022-06-21 17:17 ` Peter Foley @ 2022-06-21 19:33 ` Patrick Venture 0 siblings, 0 replies; 9+ messages in thread From: Patrick Venture @ 2022-06-21 19:33 UTC (permalink / raw) To: Peter Foley Cc: Alexander Bulekov, Thomas Huth, QEMU Developers, Marc-André Lureau, Samuel Thibault [-- Attachment #1: Type: text/plain, Size: 10694 bytes --] On Tue, Jun 21, 2022 at 10:17 AM Peter Foley <pefoley@google.com> wrote: > The upstream fixes in > https://gitlab.freedesktop.org/slirp/libslirp/-/commit/6489ebbc691f5d97221ad154d570a231e30fb369 > and > https://gitlab.freedesktop.org/slirp/libslirp/-/commit/cc20d9ac578aec5502dcb26557765d3e9433cb26 > resolved the failure we were seeing in our internal test-case. > Thanks! > Thanks for posting the resolution commits! > > On Tue, Jun 21, 2022 at 12:47 PM Patrick Venture <venture@google.com> > wrote: > >> >> >> On Fri, Jun 17, 2022 at 7:37 AM Alexander Bulekov <alxndr@bu.edu> wrote: >> >>> On 220617 1217, Thomas Huth wrote: >>> > 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 >>> catches >>> > > > > >>> > > > >>> > > > Yeah - 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? >>> >>> Done: >>> https://gitlab.freedesktop.org/slirp/libslirp/-/issues/62 >>> https://gitlab.freedesktop.org/slirp/libslirp/-/issues/63 >> >> >> Thank you! >> >>> >>> >>> -Alex >>> >>> > >>> > 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#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 >>> > > > > >>> > > >>> > >>> >> [-- Attachment #2: Type: text/html, Size: 14959 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-06-21 19:36 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-06-15 16:42 misaligned-pointer-use libslirp/src/tcp_input.c Patrick Venture 2022-06-16 13:30 ` Alexander Bulekov 2022-06-16 16:30 ` Patrick Venture 2022-06-16 19:03 ` Alexander Bulekov 2022-06-17 10:17 ` Thomas Huth 2022-06-17 14:37 ` Alexander Bulekov 2022-06-21 16:47 ` Patrick Venture 2022-06-21 17:17 ` Peter Foley 2022-06-21 19:33 ` Patrick Venture
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).