| Message ID | 20200507105718.1319187-1-ppandit@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | use unsigned type for MegasasState fields | expand |
+-- On Thu, 7 May 2020, P J P wrote --+ | Hello, | | * This series fixes an OOB access issue which may occur when a guest user | sets 's->reply_queue_head' field to a negative(or large positive) value, | via 'struct mfi_init_qinfo' object in megasas_init_firmware(). | | * Second patch updates other numeric fields of MegasasState to unsigned type. | | Thank you. | --- | Prasad J Pandit (2): | megasas: use unsigned type for reply_queue_head | megasas: use unsigned type for positive numeric fields | | hw/scsi/megasas.c | 40 ++++++++++++++++++++-------------------- | 1 file changed, 20 insertions(+), 20 deletions(-) Ping...! -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Cc'ing Marc-André our signed/unsigned conversion expert (with Paolo). On 5/7/20 12:57 PM, P J P wrote: > From: Prasad J Pandit <pjp@fedoraproject.org> > > Hello, > > * This series fixes an OOB access issue which may occur when a guest user > sets 's->reply_queue_head' field to a negative(or large positive) value, > via 'struct mfi_init_qinfo' object in megasas_init_firmware(). Do you have a reproducer? > > * Second patch updates other numeric fields of MegasasState to unsigned type. > > Thank you. > --- > Prasad J Pandit (2): > megasas: use unsigned type for reply_queue_head > megasas: use unsigned type for positive numeric fields > > hw/scsi/megasas.c | 40 ++++++++++++++++++++-------------------- > 1 file changed, 20 insertions(+), 20 deletions(-) >
+-- 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
Hi all,
To clarify, the bug has been reported 6 months ago with the commit version of 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d, which was the upstream back then. The reproducing driver along with the ASAN log we provided was for that version specifically.
Thanks,
Ren
发件人: P J P<mailto:ppandit@redhat.com>
发送时间: 2020年5月12日 14:37
收件人: Philippe Mathieu-Daudé<mailto:philmd@redhat.com>
抄送: QEMU Developers<mailto:qemu-devel@nongnu.org>; Fam Zheng<mailto:fam@euphon.net>; Paolo Bonzini<mailto:pbonzini@redhat.com>; Ding, Ren<mailto:rding@gatech.edu>; Marc-André Lureau<mailto:marcandre.lureau@redhat.com>
主题: Re: [PATCH 0/2] use unsigned type for MegasasState fields
+-- 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
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
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): 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 > >
Hi Ren, On 5/12/20 8:49 PM, Ding, Ren wrote: > Hi all, > > To clarify, the bug has been reported 6 months ago with the commit > version of 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d, which was the > upstream back then. The reproducing driver along with the ASAN log we > provided was for that version specifically. When I first read I thought you'd have miswriten 'months' for 'days' or 'weeks', but this commit is 6 *months* old indeed. The cover describes the bug as OOB, so I suppose this is a security issue. Now a 6 months embargo surprises me. I was expecting some period in a 30-90days range to be the default. However reading the 'Publication embargo' chapter on https://www.qemu.org/contribute/security-process/, it is only stated "Embargo periods will be negotiated by mutual agreement between members of the security team and other relevant parties to the problem." Shouldn't be a maximum upper limit on the embargo period? Are there QEMU security bugs embargoed for more than a year? That would be a shame. > > Thanks, > > Ren > > *发件人: *P J P <mailto:ppandit@redhat.com> > *发送时间: *2020年5月12日14:37 > *收件人: *Philippe Mathieu-Daudé <mailto:philmd@redhat.com> > *抄送: *QEMU Developers <mailto:qemu-devel@nongnu.org>; Fam Zheng > <mailto:fam@euphon.net>; Paolo Bonzini <mailto:pbonzini@redhat.com>; > Ding, Ren <mailto:rding@gatech.edu>; Marc-André Lureau > <mailto:marcandre.lureau@redhat.com> > *主题: *Re: [PATCH 0/2] use unsigned type for MegasasState fields > > +-- 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 This is previous information useful for the commit description, thanks for sharing it! > > > Thank you. > -- > Prasad J Pandit / Red Hat Product Security Team > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D >
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 >> >> >
On 200512 2259, Philippe Mathieu-Daudé wrote: > 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 I don't think so, though they may be related, of course. > > > > 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 > > > > > > > > >
+-- On Tue, 12 May 2020, Philippe Mathieu-Daudé wrote --+ | The cover describes the bug as OOB, so I suppose this is a security issue. | Now a 6 months embargo surprises me. I was expecting some period in a | 30-90days range to be the default. However reading the 'Publication embargo' | chapter on https://www.qemu.org/contribute/security-process/, it is only | stated "Embargo periods will be negotiated by mutual agreement between | members of the security team and other relevant parties to the problem." | Shouldn't be a maximum upper limit on the embargo period? Are there QEMU | security bugs embargoed for more than a year? That would be a shame. Yes, some of these issue are old. We are working on the time-line details. We have quite regular influx of CVE issues, which leads to long triage times for some of them. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Hello Alex, +-- On Tue, 12 May 2020, Alexander Bulekov wrote --+ | ==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): | | 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 Thanks much for this, will try it. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Hello Alex, +-- On Tue, 12 May 2020, Alexander Bulekov wrote --+ | 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: Strange, because with uint16_t type, 'reply_queue_head' should not turn negative. | 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 Are qemu options just above EOF right? This leads to an assert failure below qemu/qtest.c:546:qtest_process_command: assertion failed: (words[1] && words[2] && words[3]) ... Aborted (core dumped) /tmp/im/bin/qemu-system-x86_64 -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 < ins Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
On 200513 1919, P J P wrote: > Hello Alex, > > +-- On Tue, 12 May 2020, Alexander Bulekov wrote --+ > | 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: > > Strange, because with uint16_t type, 'reply_queue_head' should not turn > negative. > > | 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 > > Are qemu options just above EOF right? They are not necessary, but for me QEMU crashes before qtest ever tries to parse them. Is your QEMU built with ASAN? -Alex > > This leads to an assert failure below > > qemu/qtest.c:546:qtest_process_command: assertion failed: (words[1] && words[2] && words[3]) > ... > Aborted (core dumped) /tmp/im/bin/qemu-system-x86_64 -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 < ins > > > Thank you. > -- > Prasad J Pandit / Red Hat Product Security Team > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D >
On 200513 1919, P J P wrote: > Hello Alex, > > +-- On Tue, 12 May 2020, Alexander Bulekov wrote --+ > | 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: > > Strange, because with uint16_t type, 'reply_queue_head' should not turn > negative. > > | 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 > > Are qemu options just above EOF right? > > This leads to an assert failure below > > qemu/qtest.c:546:qtest_process_command: assertion failed: (words[1] && words[2] && words[3]) > ... > Aborted (core dumped) /tmp/im/bin/qemu-system-x86_64 -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 < ins Also, this assertion seems to happen while parsing one of the "write" commands. Maybe the formatting was corrupted in the email. I uploaded the commands here, just in case: wget https://paste.debian.net/plain/1146573 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 < 1146573 -Alex > > Thank you. > -- > Prasad J Pandit / Red Hat Product Security Team > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D >
+-- On Wed, 13 May 2020, Alexander Bulekov wrote --+ | They are not necessary, but for me QEMU crashes before qtest ever tries to | parse them. Is your QEMU built with ASAN? Yes, it is QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -fsanitize=address QEMU_LDFLAGS -Wl,--warn-common -fsanitize=address Btw, Ren confirmed that he wasn't able to reproduce the issue with the proposed patch. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Hi all, We couldn’t reproduce the bug with the patch provided by our reproducer earlier, though we did not dig into the details of it. Meanwhile, we do also see the null pointer dereference crash with the current upstream (https://bugs.launchpad.net/qemu/+bug/1878259). Ren On May 13, 2020, at 10:53 AM, P J P <ppandit@redhat.com<mailto:ppandit@redhat.com>> wrote: +-- On Wed, 13 May 2020, Alexander Bulekov wrote --+ | They are not necessary, but for me QEMU crashes before qtest ever tries to | parse them. Is your QEMU built with ASAN? Yes, it is QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -fsanitize=address QEMU_LDFLAGS -Wl,--warn-common -fsanitize=address Btw, Ren confirmed that he wasn't able to reproduce the issue with the proposed patch. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Hello Ren, Alex, +-- On Wed, 13 May 2020, Ding, Ren wrote --+ | We couldn’t reproduce the bug with the patch provided by our reproducer | earlier, though we did not dig into the details of it. Meanwhile, we do also | see the null pointer dereference crash with the current upstream | (https://bugs.launchpad.net/qemu/+bug/1878259). * Yes, I was able to reproduce both OOB access and NULL dereference issues with Alex's reproducers. * I have sent revised patches v2 with you in CC. I've tested the patches, still please kindly confirm if they work for you OR if you see anything amiss. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
From: Prasad J Pandit <pjp@fedoraproject.org> Hello, * This series fixes an OOB access issue which may occur when a guest user sets 's->reply_queue_head' field to a negative(or large positive) value, via 'struct mfi_init_qinfo' object in megasas_init_firmware(). * Second patch updates other numeric fields of MegasasState to unsigned type. Thank you. --- Prasad J Pandit (2): megasas: use unsigned type for reply_queue_head megasas: use unsigned type for positive numeric fields hw/scsi/megasas.c | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-)