qemu-devel
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: misaligned-pointer-use libslirp/src/tcp_input.c

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 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
reply via email to
[Prev in Thread] Current Thread [Next in Thread]