* [PATCH 0/2] use unsigned type for MegasasState fields
@ 2020-05-07 10:57 P J P
2020-05-07 10:57 ` [PATCH 1/2] megasas: use unsigned type for reply_queue_head P J P
` (3 more replies)
0 siblings, 4 replies; 23+ messages in thread
From: P J P @ 2020-05-07 10:57 UTC (permalink / raw)
To: QEMU Developers; +Cc: Fam Zheng, Paolo Bonzini, Prasad J Pandit, Ren Ding
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(-)
--
2.25.4
^ permalink raw reply [flat|nested] 23+ messages in thread* [PATCH 1/2] megasas: use unsigned type for reply_queue_head 2020-05-07 10:57 [PATCH 0/2] use unsigned type for MegasasState fields P J P @ 2020-05-07 10:57 ` P J P 2020-05-12 18:52 ` Peter Maydell 2020-05-07 10:57 ` [PATCH 2/2] megasas: use unsigned type for positive numeric fields P J P ` (2 subsequent siblings) 3 siblings, 1 reply; 23+ messages in thread From: P J P @ 2020-05-07 10:57 UTC (permalink / raw) To: QEMU Developers; +Cc: Fam Zheng, Paolo Bonzini, Prasad J Pandit, Ren Ding From: Prasad J Pandit <pjp@fedoraproject.org> A guest user may set 's->reply_queue_head' MegasasState field to a negative value. Later in 'megasas_lookup_frame' it is used to index into s->frames[] array. Use unsigned type to avoid OOB access issue. Reported-by: Ren Ding <rding@gatech.edu> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> --- hw/scsi/megasas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c index af18c88b65..433353bad0 100644 --- a/hw/scsi/megasas.c +++ b/hw/scsi/megasas.c @@ -112,7 +112,7 @@ typedef struct MegasasState { uint64_t reply_queue_pa; void *reply_queue; int reply_queue_len; - int reply_queue_head; + uint16_t reply_queue_head; int reply_queue_tail; uint64_t consumer_pa; uint64_t producer_pa; -- 2.25.4 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 1/2] megasas: use unsigned type for reply_queue_head 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 0 siblings, 1 reply; 23+ messages in thread From: Peter Maydell @ 2020-05-12 18:52 UTC (permalink / raw) To: P J P Cc: Fam Zheng, Paolo Bonzini, QEMU Developers, Ren Ding, Prasad J Pandit On Thu, 7 May 2020 at 12:03, P J P <ppandit@redhat.com> wrote: > > From: Prasad J Pandit <pjp@fedoraproject.org> > > A guest user may set 's->reply_queue_head' MegasasState field to > a negative value. Later in 'megasas_lookup_frame' it is used to > index into s->frames[] array. Use unsigned type to avoid OOB > access issue. > > Reported-by: Ren Ding <rding@gatech.edu> > Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> > --- > hw/scsi/megasas.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c > index af18c88b65..433353bad0 100644 > --- a/hw/scsi/megasas.c > +++ b/hw/scsi/megasas.c > @@ -112,7 +112,7 @@ typedef struct MegasasState { > uint64_t reply_queue_pa; > void *reply_queue; > int reply_queue_len; > - int reply_queue_head; > + uint16_t reply_queue_head; > int reply_queue_tail; > uint64_t consumer_pa; > uint64_t producer_pa; Using a 16-bit type here means that code like this: s->reply_queue_head = ldl_le_pci_dma(pcid, s->producer_pa); s->reply_queue_head %= MEGASAS_MAX_FRAMES; suddenly does a truncation of the 32-bit loaded value before the modulus operation, which is a bit odd, though since MEGASAS_MAX_FRAMES happens to be a power of 2 the end result won't change. It's also a bit weird to change reply_queue_head's type but not reply_queue_tail or reply_queue_len. thanks -- PMM ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/2] megasas: use unsigned type for reply_queue_head 2020-05-12 18:52 ` Peter Maydell @ 2020-05-13 11:20 ` P J P 0 siblings, 0 replies; 23+ messages in thread From: P J P @ 2020-05-13 11:20 UTC (permalink / raw) To: Peter Maydell; +Cc: Fam Zheng, Paolo Bonzini, QEMU Developers, Ren Ding +-- On Tue, 12 May 2020, Peter Maydell wrote --+ | > + uint16_t reply_queue_head; | | Using a 16-bit type here means that code like this: | | s->reply_queue_head = ldl_le_pci_dma(pcid, s->producer_pa); | s->reply_queue_head %= MEGASAS_MAX_FRAMES; | | suddenly does a truncation of the 32-bit loaded value before | the modulus operation, which is a bit odd, though since | MEGASAS_MAX_FRAMES happens to be a power of 2 the end | result won't change. Yes, 16-bit also for its range of value is limitted to MEGASAS_MAX_FRAMES=2048. | It's also a bit weird to change reply_queue_head's type | but not reply_queue_tail or reply_queue_len. That's in the second patch. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 2/2] megasas: use unsigned type for positive numeric fields 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-07 10:57 ` P J P 2020-05-12 18:53 ` Peter Maydell 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é 3 siblings, 1 reply; 23+ messages in thread From: P J P @ 2020-05-07 10:57 UTC (permalink / raw) To: QEMU Developers; +Cc: Fam Zheng, Paolo Bonzini, Prasad J Pandit, Ren Ding From: Prasad J Pandit <pjp@fedoraproject.org> Use unsigned type for the MegasasState fields which hold positive numeric values. Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> --- hw/scsi/megasas.c | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c index 433353bad0..fffcb18bdb 100644 --- a/hw/scsi/megasas.c +++ b/hw/scsi/megasas.c @@ -86,34 +86,34 @@ typedef struct MegasasState { MemoryRegion queue_io; uint32_t frame_hi; - int fw_state; + uint32_t fw_state; uint32_t fw_sge; uint32_t fw_cmds; uint32_t flags; - int fw_luns; - int intr_mask; - int doorbell; - int busy; - int diag; - int adp_reset; + uint32_t fw_luns; + uint32_t intr_mask; + uint32_t doorbell; + uint32_t busy; + uint32_t diag; + uint32_t adp_reset; OnOffAuto msi; OnOffAuto msix; MegasasCmd *event_cmd; - int event_locale; + uint16_t event_locale; int event_class; - int event_count; - int shutdown_event; - int boot_event; + uint32_t event_count; + uint32_t shutdown_event; + uint32_t boot_event; uint64_t sas_addr; char *hba_serial; uint64_t reply_queue_pa; void *reply_queue; - int reply_queue_len; + uint16_t reply_queue_len; uint16_t reply_queue_head; - int reply_queue_tail; + uint16_t reply_queue_tail; uint64_t consumer_pa; uint64_t producer_pa; @@ -2259,9 +2259,9 @@ static const VMStateDescription vmstate_megasas_gen1 = { VMSTATE_PCI_DEVICE(parent_obj, MegasasState), VMSTATE_MSIX(parent_obj, MegasasState), - VMSTATE_INT32(fw_state, MegasasState), - VMSTATE_INT32(intr_mask, MegasasState), - VMSTATE_INT32(doorbell, MegasasState), + VMSTATE_UINT32(fw_state, MegasasState), + VMSTATE_UINT32(intr_mask, MegasasState), + VMSTATE_UINT32(doorbell, MegasasState), VMSTATE_UINT64(reply_queue_pa, MegasasState), VMSTATE_UINT64(consumer_pa, MegasasState), VMSTATE_UINT64(producer_pa, MegasasState), @@ -2278,9 +2278,9 @@ static const VMStateDescription vmstate_megasas_gen2 = { VMSTATE_PCI_DEVICE(parent_obj, MegasasState), VMSTATE_MSIX(parent_obj, MegasasState), - VMSTATE_INT32(fw_state, MegasasState), - VMSTATE_INT32(intr_mask, MegasasState), - VMSTATE_INT32(doorbell, MegasasState), + VMSTATE_UINT32(fw_state, MegasasState), + VMSTATE_UINT32(intr_mask, MegasasState), + VMSTATE_UINT32(doorbell, MegasasState), VMSTATE_UINT64(reply_queue_pa, MegasasState), VMSTATE_UINT64(consumer_pa, MegasasState), VMSTATE_UINT64(producer_pa, MegasasState), -- 2.25.4 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] megasas: use unsigned type for positive numeric fields 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 0 siblings, 1 reply; 23+ messages in thread From: Peter Maydell @ 2020-05-12 18:53 UTC (permalink / raw) To: P J P Cc: Fam Zheng, Paolo Bonzini, QEMU Developers, Ren Ding, Prasad J Pandit On Thu, 7 May 2020 at 12:02, P J P <ppandit@redhat.com> wrote: > > From: Prasad J Pandit <pjp@fedoraproject.org> > > Use unsigned type for the MegasasState fields which hold positive > numeric values. > > Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> > --- > @@ -2259,9 +2259,9 @@ static const VMStateDescription vmstate_megasas_gen1 = { > VMSTATE_PCI_DEVICE(parent_obj, MegasasState), > VMSTATE_MSIX(parent_obj, MegasasState), > > - VMSTATE_INT32(fw_state, MegasasState), > - VMSTATE_INT32(intr_mask, MegasasState), > - VMSTATE_INT32(doorbell, MegasasState), > + VMSTATE_UINT32(fw_state, MegasasState), > + VMSTATE_UINT32(intr_mask, MegasasState), > + VMSTATE_UINT32(doorbell, MegasasState), > VMSTATE_UINT64(reply_queue_pa, MegasasState), > VMSTATE_UINT64(consumer_pa, MegasasState), > VMSTATE_UINT64(producer_pa, MegasasState), > @@ -2278,9 +2278,9 @@ static const VMStateDescription vmstate_megasas_gen2 = { > VMSTATE_PCI_DEVICE(parent_obj, MegasasState), > VMSTATE_MSIX(parent_obj, MegasasState), > > - VMSTATE_INT32(fw_state, MegasasState), > - VMSTATE_INT32(intr_mask, MegasasState), > - VMSTATE_INT32(doorbell, MegasasState), > + VMSTATE_UINT32(fw_state, MegasasState), > + VMSTATE_UINT32(intr_mask, MegasasState), > + VMSTATE_UINT32(doorbell, MegasasState), > VMSTATE_UINT64(reply_queue_pa, MegasasState), > VMSTATE_UINT64(consumer_pa, MegasasState), > VMSTATE_UINT64(producer_pa, MegasasState), Does an INT32->UINT32 change in vmstate break migration compat? I forget, but this is the kind of detail it's worth calling out in the commit message if you've checked and it really is still compatible. thanks -- PMM ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] megasas: use unsigned type for positive numeric fields 2020-05-12 18:53 ` Peter Maydell @ 2020-05-13 11:22 ` P J P 0 siblings, 0 replies; 23+ messages in thread From: P J P @ 2020-05-13 11:22 UTC (permalink / raw) To: Peter Maydell; +Cc: Fam Zheng, Paolo Bonzini, QEMU Developers, Ren Ding +-- On Tue, 12 May 2020, Peter Maydell wrote --+ | Does an INT32->UINT32 change in vmstate break migration compat? I forget, | but this is the kind of detail it's worth calling out in the commit message | if you've checked and it really is still compatible. No, not sure. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 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-07 10:57 ` [PATCH 2/2] megasas: use unsigned type for positive numeric fields P J P @ 2020-05-12 12:21 ` P J P 2020-05-12 13:42 ` Philippe Mathieu-Daudé 3 siblings, 0 replies; 23+ messages in thread From: P J P @ 2020-05-12 12:21 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Fam Zheng, Ren Ding, QEMU Developers +-- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-07 10:57 [PATCH 0/2] use unsigned type for MegasasState fields P J P ` (2 preceding siblings ...) 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 3 siblings, 1 reply; 23+ messages in thread From: Philippe Mathieu-Daudé @ 2020-05-12 13:42 UTC (permalink / raw) To: P J P, QEMU Developers Cc: Fam Zheng, Paolo Bonzini, Prasad J Pandit, Ren Ding, Marc-André Lureau 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(-) > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 13:42 ` Philippe Mathieu-Daudé @ 2020-05-12 18:37 ` P J P 2020-05-12 19:08 ` Alexander Bulekov [not found] ` <BN6PR07MB341283EBBF78F86AAA995382CABE0@BN6PR07MB3412.namprd07.prod.outlook.com> 0 siblings, 2 replies; 23+ messages in thread From: P J P @ 2020-05-12 18:37 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Fam Zheng, Paolo Bonzini, QEMU Developers, Ren Ding, Marc-André Lureau [-- Attachment #1: Type: text/plain, Size: 2668 bytes --] +-- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 18:37 ` P J P @ 2020-05-12 19:08 ` Alexander Bulekov 2020-05-12 19:48 ` Alexander Bulekov [not found] ` <BN6PR07MB341283EBBF78F86AAA995382CABE0@BN6PR07MB3412.namprd07.prod.outlook.com> 1 sibling, 1 reply; 23+ messages in thread From: Alexander Bulekov @ 2020-05-12 19:08 UTC (permalink / raw) To: P J P Cc: Fam Zheng, QEMU Developers, Marc-André Lureau, Ren Ding, Paolo Bonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 19:08 ` Alexander Bulekov @ 2020-05-12 19:48 ` Alexander Bulekov 2020-05-12 20:59 ` Philippe Mathieu-Daudé ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Alexander Bulekov @ 2020-05-12 19:48 UTC (permalink / raw) To: P J P Cc: Fam Zheng, QEMU Developers, Paolo Bonzini, Ren Ding, Marc-André Lureau, Philippe Mathieu-Daudé 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 > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 19:48 ` Alexander Bulekov @ 2020-05-12 20:59 ` Philippe Mathieu-Daudé 2020-05-12 21:00 ` Alexander Bulekov 2020-05-13 11:13 ` P J P 2020-05-13 13:49 ` P J P 2 siblings, 1 reply; 23+ messages in thread From: Philippe Mathieu-Daudé @ 2020-05-12 20:59 UTC (permalink / raw) To: Alexander Bulekov, P J P Cc: Fam Zheng, Marc-André Lureau, QEMU Developers, Ren Ding, Paolo Bonzini 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 >> >> > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 20:59 ` Philippe Mathieu-Daudé @ 2020-05-12 21:00 ` Alexander Bulekov 0 siblings, 0 replies; 23+ messages in thread From: Alexander Bulekov @ 2020-05-12 21:00 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Fam Zheng, QEMU Developers, P J P, Paolo Bonzini, Ren Ding, Marc-André Lureau 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 > > > > > > > > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 19:48 ` Alexander Bulekov 2020-05-12 20:59 ` Philippe Mathieu-Daudé @ 2020-05-13 11:13 ` P J P 2020-05-13 13:49 ` P J P 2 siblings, 0 replies; 23+ messages in thread From: P J P @ 2020-05-13 11:13 UTC (permalink / raw) To: Alexander Bulekov Cc: Fam Zheng, QEMU Developers, Paolo Bonzini, Ren Ding, Marc-André Lureau, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 19:48 ` Alexander Bulekov 2020-05-12 20:59 ` Philippe Mathieu-Daudé 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 ` Alexander Bulekov 2 siblings, 2 replies; 23+ messages in thread From: P J P @ 2020-05-13 13:49 UTC (permalink / raw) To: Alexander Bulekov Cc: Fam Zheng, QEMU Developers, Paolo Bonzini, Ren Ding, Marc-André Lureau, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 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 14:53 ` Alexander Bulekov 1 sibling, 1 reply; 23+ messages in thread From: Alexander Bulekov @ 2020-05-13 14:20 UTC (permalink / raw) To: P J P Cc: Fam Zheng, QEMU Developers, Paolo Bonzini, Ren Ding, Marc-André Lureau, Philippe Mathieu-Daudé 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-13 14:20 ` Alexander Bulekov @ 2020-05-13 14:53 ` P J P 2020-05-13 17:08 ` Ding, Ren 0 siblings, 1 reply; 23+ messages in thread From: P J P @ 2020-05-13 14:53 UTC (permalink / raw) To: Alexander Bulekov Cc: Fam Zheng, QEMU Developers, Paolo Bonzini, Ren Ding, Marc-André Lureau, Philippe Mathieu-Daudé +-- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-13 14:53 ` P J P @ 2020-05-13 17:08 ` Ding, Ren 2020-05-13 19:34 ` P J P 0 siblings, 1 reply; 23+ messages in thread From: Ding, Ren @ 2020-05-13 17:08 UTC (permalink / raw) To: P J P Cc: Fam Zheng, QEMU Developers, Alexander Bulekov, Marc-André Lureau, Ding, Ren, Paolo Bonzini, Philippe Mathieu-Daudé [-- Attachment #1: Type: text/plain, Size: 911 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 1840 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-13 17:08 ` Ding, Ren @ 2020-05-13 19:34 ` P J P 0 siblings, 0 replies; 23+ messages in thread From: P J P @ 2020-05-13 19:34 UTC (permalink / raw) To: Ding, Ren, Alexander Bulekov Cc: Fam Zheng, Marc-André Lureau, Philippe Mathieu-Daudé, QEMU Developers, Paolo Bonzini [-- Attachment #1: Type: text/plain, Size: 716 bytes --] 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-13 13:49 ` P J P 2020-05-13 14:20 ` Alexander Bulekov @ 2020-05-13 14:53 ` Alexander Bulekov 1 sibling, 0 replies; 23+ messages in thread From: Alexander Bulekov @ 2020-05-13 14:53 UTC (permalink / raw) To: P J P Cc: Fam Zheng, QEMU Developers, Paolo Bonzini, Ren Ding, Marc-André Lureau, Philippe Mathieu-Daudé 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <BN6PR07MB341283EBBF78F86AAA995382CABE0@BN6PR07MB3412.namprd07.prod.outlook.com>]
* Re: 回复: [PATCH 0/2] use unsigned type for MegasasState fields [not found] ` <BN6PR07MB341283EBBF78F86AAA995382CABE0@BN6PR07MB3412.namprd07.prod.outlook.com> @ 2020-05-12 20:54 ` Philippe Mathieu-Daudé 2020-05-13 11:07 ` P J P 0 siblings, 1 reply; 23+ messages in thread From: Philippe Mathieu-Daudé @ 2020-05-12 20:54 UTC (permalink / raw) To: Ding, Ren, P J P Cc: Fam Zheng, Paolo Bonzini, QEMU Developers, Zhao, Hanqing, Marc-André Lureau 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: 回复: [PATCH 0/2] use unsigned type for MegasasState fields 2020-05-12 20:54 ` 回复: " Philippe Mathieu-Daudé @ 2020-05-13 11:07 ` P J P 0 siblings, 0 replies; 23+ messages in thread From: P J P @ 2020-05-13 11:07 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Fam Zheng, QEMU Developers, Paolo Bonzini, Ding, Ren, Marc-André Lureau, Zhao, Hanqing [-- Attachment #1: Type: text/plain, Size: 948 bytes --] +-- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-05-13 19:36 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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é
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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.