All of lore.kernel.org
 help / color / mirror / Atom feed
* [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
* [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 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 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 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 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
       [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 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 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
* 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 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
* 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-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 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
* 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
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.