From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Alexander Bulekov <alxndr@bu.edu>, P J P <ppandit@redhat.com>
Cc: "Fam Zheng" <fam@euphon.net>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Ren Ding" <rding@gatech.edu>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH 0/2] use unsigned type for MegasasState fields
Date: Tue, 12 May 2020 22:59:01 +0200 [thread overview]
Message-ID: <810b7ee0-e3eb-cd08-887a-df97a8576c9c@redhat.com> (raw)
In-Reply-To: <20200512194759.nb42yurlnynr5yrw@mozz.bu.edu>
On 5/12/20 9:48 PM, Alexander Bulekov wrote:
> Oops I realized I posted a bad stacktrace and a bad reproducer :)
> Fixed stacktrace:
>
> ==20527==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f79f968a5e0 at pc 0x55b6bb84ce28 bp 0x7ffcbca04eb0 sp 0x7ffcbca04ea8
> READ of size 8 at 0x7f79f968a5e0 thread T0
>
> #0 0x55fbeb2bdafc in megasas_lookup_frame /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:449:30
> #1 0x55fbeb27caa9 in megasas_handle_abort /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:1904:17
> #2 0x55fbeb26cb77 in megasas_handle_frame /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:1961:24
> #3 0x55fbeb267b78 in megasas_mmio_write /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:2122:9
> #4 0x55fbe90b117b in memory_region_write_accessor /home/alxndr/Development/qemu-bugs/qemu2/qemu/memory.c:496:5
> #5 0x55fbe90b05e4 in access_with_adjusted_size /home/alxndr/Development/qemu-bugs/qemu2/qemu/memory.c:557:18
> #6 0x55fbe90ae177 in memory_region_dispatch_write /home/alxndr/Development/qemu-bugs/qemu2/qemu/memory.c:1488:16
> #7 0x55fbe8d97325 in flatview_write_continue /home/alxndr/Development/qemu-bugs/qemu2/qemu/exec.c:3174:23
>
> Fixed reproducer (tested on qemu 5.0 built with ASAN with these patches):
Is this the one reported as LP#1878259?
"Null-pointer dereference in megasas_handle_frame"
https://bugs.launchpad.net/qemu/+bug/1878259
>
> cat << EOF | qemu-system-i386 -qtest stdio -nographic -monitor none \
> -serial none -M q35 -device megasas -device scsi-cd,drive=null0 \
> -blockdev driver=null-co,read-zeroes=on,node-name=null0 -nographic
> outl 0xcf8 0x80001814
> outl 0xcfc 0xc021
> outl 0xcf8 0x80001818
> outl 0xcf8 0x80001804
> outw 0xcfc 0x7
> outl 0xcf8 0x80001810
> outl 0xcfc 0xe10c0000
> outl 0xcf8 0x8000f810
> write 0x0 0x18 0x060017e1ff00f8ffffffff60efffffffffffffffffffffff
> write 0xff00 0x1 0x06
> write 0xc021e10c0040 0x81 0x755e08ff0000845e08ff0000935e08ff0000a25e08ff0000b15e08ff0000c05e08ff0000cf5e08ff0000de5e08ff0000ed5e08ff0000fc5e08ff00000b5e08ff00001a5e08ff0000295e08ff0000385e08ff0000475e08ff0000565e08ff0000655e08ff0000745e08ff0000835e08ff0000925e08ff0000a15e08ff0000b05e08
> -M pc-q35-5.0 -no-shutdown -M q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 -nographic
>
> EOF
>
> On 200512 1508, Alexander Bulekov wrote:
>> Hello Prasad,
>> I noticed this since I found a similar issue recently, using a fuzzer.
>> I applied your patches, but I can still reproduce the heap-overflow,
>> unless I'm missing something:
>>
>> ==20527==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f79f968a5e0 at pc 0x55b6bb84ce28 bp 0x7ffcbca04eb0 sp 0x7ffcbca04ea8
>> READ of size 8 at 0x7f79f968a5e0 thread T0
>> #0 0x55fbeb2bdafc in megasas_lookup_frame /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:449:30
>> #0 0x55b6bb84ce27 in megasas_lookup_frame (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x1c1fe27)
>> #1 0x55b6bb82f3e4 in megasas_handle_abort (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x1c023e4)
>> #2 0x55b6bb8293df in megasas_handle_frame (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x1bfc3df)
>> #3 0x55b6bb8275eb in megasas_mmio_write (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x1bfa5eb)
>> #4 0x55b6bab5c864 in memory_region_write_accessor (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xf2f864)
>> #5 0x55b6bab5c239 in access_with_adjusted_size (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xf2f239)
>> #6 0x55b6bab5ada5 in memory_region_dispatch_write (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xf2dda5)
>> #7 0x55b6ba994bf3 in flatview_write_continue (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xd67bf3)
>> #8 0x55b6ba984ad8 in flatview_write (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xd57ad8)
>> #1 0x55fbeb27caa9 in megasas_handle_abort /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:1904:17
>> #2 0x55fbeb26cb77 in megasas_handle_frame /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:1961:24
>> #3 0x55fbeb267b78 in megasas_mmio_write /home/alxndr/Development/qemu-bugs/qemu2/qemu/hw/scsi/megasas.c:2122:9
>> #4 0x55fbe90b117b in memory_region_write_accessor /home/alxndr/Development/qemu-bugs/qemu2/qemu/memory.c:496:5
>> #5 0x55fbe90b05e4 in access_with_adjusted_size /home/alxndr/Development/qemu-bugs/qemu2/qemu/memory.c:557:18
>> #6 0x55fbe90ae177 in memory_region_dispatch_write /home/alxndr/Development/qemu-bugs/qemu2/qemu/memory.c:1488:16
>> #7 0x55fbe8d97325 in flatview_write_continue /home/alxndr/Development/qemu-bugs/qemu2/qemu/exec.c:3174:23
>>
>> To reproduce:
>> cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -qtest stdio -nographic -monitor none -serial none -M q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 -nographic
>> outl 0xcf8 0x80001814
>> outl 0xcfc 0xc021
>> outl 0xcf8 0x80001818
>> outl 0xcf8 0x80001804
>> outw 0xcfc 0x7
>> outl 0xcf8 0x80001810
>> outl 0xcfc 0xe10c0000
>> outl 0xcf8 0x8000f810
>> write 0x0 0x18 0x060017e1ff00f8ffffffff60efffffffffffffffffffffff
>> write 0xff00 0x1 0x06
>> write 0xc021e10c0040 0x81 0x755e08ff0000845e08ff0000935e08ff0000a25e08ff0000b15e08ff0000c05e08ff0000cf5e08ff0000de5e08ff0000ed5e08ff0000fc5e08ff00000b5e08ff00001a5e08ff0000295e08ff0000385e08ff0000475e08ff0000565e08ff0000655e08ff0000745e08ff0000835e08ff0000925e08ff0000a15e08ff0000b05e08
>> -M pc-q35-5.0 -no-shutdown -M q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 -nographic
>> EOF
>>
>> -Alex
>>
>> On 200513 0007, P J P wrote:
>>> +-- On Tue, 12 May 2020, Philippe Mathieu-Daudé wrote --+
>>> | Cc'ing Marc-André our signed/unsigned conversion expert (with Paolo).
>>>
>>> megasas_init_firmware
>>> pa_lo = le32_to_cpu(initq->pi_addr_lo);
>>> pa_hi = le32_to_cpu(initq->pi_addr_hi);
>>> s->producer_pa = ((uint64_t) pa_hi << 32) | pa_lo;
>>> s->reply_queue_head = ldl_le_pci_dma(pcid, s->producer_pa);
>>>
>>> IIUC, here ldl_le_pci_dma() returns an 'uint32_t' type, but since
>>> 'reply_queue_head' is a signed int, large 'uint32_t' value turns negative.
>>>
>>> | Do you have a reproducer?
>>>
>>> Yes, there is a reproducer with ASAN, though it did not work for me.
>>> Ren(CC'd) had shared this trace:
>>>
>>> AddressSanitizer: heap-buffer-overflow on address 0x7f9159054058 at pc 0x55763514b5cd bp 0x7f9179bd6d90 sp 0x7f9179bd6d88
>>> READ of size 8 at 0x7f9159054058 thread T2
>>> #0 0x55763514b5cc in megasas_lookup_frame /home/ren/tmp/redacted-dbg/qemu/hw/scsi/megasas.c:449:30
>>> #1 0x55763513205c in megasas_handle_abort /home/ren/tmp/redacted-dbg/qemu/hw/scsi/megasas.c:1904:17
>>> #2 0x55763512d0f8 in megasas_handle_frame /home/ren/tmp/redacted-dbg/qemu/hw/scsi/megasas.c:1961:24
>>> #3 0x55763512ba7d in megasas_mmio_write /home/ren/tmp/redacted-dbg/qemu/hw/scsi/megasas.c:2122:9
>>> #4 0x55763515247c in megasas_port_write /home/ren/tmp/redacted-dbg/qemu/hw/scsi/megasas.c:2173:5
>>> #5 0x557634621b3b in memory_region_write_accessor /home/ren/tmp/redacted-dbg/qemu/memory.c:483:5
>>> #6 0x557634621741 in access_with_adjusted_size /home/ren/tmp/redacted-dbg/qemu/memory.c:544:18
>>> #7 0x557634620498 in memory_region_dispatch_write /home/ren/tmp/redacted-dbg/qemu/memory.c:1482:16
>>> #8 0x5576344b6b6c in flatview_write_continue /home/ren/tmp/redacted-dbg/qemu/exec.c:3161:23
>>> #9 0x5576344a87d9 in flatview_write /home/ren/tmp/redacted-dbg/qemu/exec.c:3201:14
>>> #10 0x5576344a8376 in address_space_write /home/ren/tmp/redacted-dbg/qemu/exec.c:3291:18
>>> #11 0x5576344a8af4 in address_space_rw /home/ren/tmp/redacted-dbg/qemu/exec.c:3301:16
>>> #12 0x557634689e10 in kvm_handle_io /home/ren/tmp/redacted-dbg/qemu/accel/kvm/kvm-all.c:2086:9
>>> #13 0x557634688a45 in kvm_cpu_exec /home/ren/tmp/redacted-dbg/qemu/accel/kvm/kvm-all.c:2332:13
>>> #14 0x5576345ee7aa in qemu_kvm_cpu_thread_fn /home/ren/tmp/redacted-dbg/qemu/cpus.c:1299:17
>>> #15 0x557635a11509 in qemu_thread_start /home/ren/tmp/redacted-dbg/qemu/util/qemu-thread-posix.c:519:9
>>> #16 0x7f918cec26b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
>>> #17 0x7f918c5d441c in clone /build/glibc-LK5gWL/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>>>
>>>
>>> Thank you.
>>> --
>>> Prasad J Pandit / Red Hat Product Security Team
>>> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
>>
>>
>
next prev parent reply other threads:[~2020-05-12 21:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 10:57 [PATCH 0/2] use unsigned type for MegasasState fields P J P
2020-05-07 10:57 ` [PATCH 1/2] megasas: use unsigned type for reply_queue_head P J P
2020-05-12 18:52 ` Peter Maydell
2020-05-13 11:20 ` P J P
2020-05-07 10:57 ` [PATCH 2/2] megasas: use unsigned type for positive numeric fields P J P
2020-05-12 18:53 ` Peter Maydell
2020-05-13 11:22 ` P J P
2020-05-12 12:21 ` [PATCH 0/2] use unsigned type for MegasasState fields P J P
2020-05-12 13:42 ` Philippe Mathieu-Daudé
2020-05-12 18:37 ` P J P
2020-05-12 19:08 ` Alexander Bulekov
2020-05-12 19:48 ` Alexander Bulekov
2020-05-12 20:59 ` Philippe Mathieu-Daudé [this message]
2020-05-12 21:00 ` Alexander Bulekov
2020-05-13 11:13 ` P J P
2020-05-13 13:49 ` P J P
2020-05-13 14:20 ` Alexander Bulekov
2020-05-13 14:53 ` P J P
2020-05-13 17:08 ` Ding, Ren
2020-05-13 19:34 ` P J P
2020-05-13 14:53 ` Alexander Bulekov
[not found] ` <BN6PR07MB341283EBBF78F86AAA995382CABE0@BN6PR07MB3412.namprd07.prod.outlook.com>
2020-05-12 20:54 ` 回复: " Philippe Mathieu-Daudé
2020-05-13 11:07 ` P J P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=810b7ee0-e3eb-cd08-887a-df97a8576c9c@redhat.com \
--to=philmd@redhat.com \
--cc=alxndr@bu.edu \
--cc=fam@euphon.net \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rding@gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).