Re: [PATCH] MAINTAINERS: add reviewers for some s390 areas

On 6/23/25 12:00 PM, Matthew Rosato wrote: To improve review coverage, assign additional people as reviewers for multiple s390 sections. Signed-off-by: Matthew Rosato Acked-by: Jason J. Herne

[PATCH] linux-user/arm: Fix return value of SYS_cacheflush

Although the emulated cacheflush syscall does nothing, it still needs to return zero to indicate success. Signed-off-by: J. Neuschäfer --- linux-user/arm/cpu_loop.c | 1 + 1 file changed, 1 insertion(+) diff --git a/linux-user/arm/cpu_loop.c b/linux-user/arm/cpu_loop.c index

Re: [PATCH v4 1/2] hw/pci-host/gt64120: Fix endianness handling

Hi , Thank you for reviewing the previous versions of this patch. I've incorporated all the feedback in v4: 1. set .min_access_size=4 2. Simplified swapping to bswap32 only Note: I realized after sending v4 that the commit message still referenced the old size-specific swap approach -"Implement s

Re: [PATCH] hw/pci-host/gt64120.c: Fix PCI host bridge endianness handling

M Philippe Mathieu-Daudé wrote: > On 29/3/25 12:30, Rakesh J wrote: > > Thanks for feedback on [PATCH v1]! > > > > I've posted v2 incorporating the suggestions:ve posted v2 incorporating > > your suggestions > > > > Paolo: You pointed out the size is

Re: [PATCH v2] hw/pci-host/gt64120.c: Fix PCI host bridge endianness handling

On Sat, Mar 29, 2025 at 5:18 PM Philippe Mathieu-Daudé wrote: > Hi Rakesh, > > On 29/3/25 01:49, rakeshj wrote: > > The GT-64120 PCI controller requires special handling where: > > 1. Host bridge (device 0) must use native endianness > > 2. Other devices follow MByteSwap bit in GT_PCI0_CMD > > >

Re: [PATCH v2] hw/pci-host/gt64120.c: Fix PCI host bridge endianness handling

Thanks, BALATON I looked into PCI_BUS_NUM and PCI_SLOT from include/hw/pci/pci.h (L15-24): - PCI_BUS_NUM(x) (((x) >> 8) & 0xff)) --> bits 15-8. - PCI_SLOT(devfn) (((devfn) >> 3) & 0x1f)), which don’t align properly with the 32-bit phb->config_reg layout used in your GT-64120 . Since these macros ar

Re: [PATCH] hw/pci-host/gt64120.c: Fix PCI host bridge endianness handling

Thanks for feedback on [PATCH v1]! I've posted v2 incorporating the suggestions:ve posted v2 incorporating your suggestions Paolo: You pointed out the size issue with .min_access_size = 1 and .max_access_size = 4, where bswap32 was wrong for 2-byte accesses. I’ve fixed this with size-appropriate

Re: [PULL 1/2] linux-user: Print tid not pid with strace

On Sat, Nov 23, 2024 at 09:07:05AM -0600, Richard Henderson wrote: > From: J. Neuschäfer > > This aligns with strace, and is very useful when tracing multi-threaded > programs. The result is the same in single-threaded programs. > > Signed-off-by: J. Neuschäfer > Message-Id:

Re: [PATCH] linux-user/strace: show TID instead of PID

On Thu, Oct 24, 2024 at 01:47:31AM +0200, J. Neuschäfer wrote: > This aligns with strace, and is very useful when tracing multi-threaded > programs. The result is the same in single-threaded programs. > > gettid() requires the _GNU_SOURCE feature test macro, so it might be > unav

[PATCH] linux-user/strace: show TID instead of PID

mplemented by both glibc and musl. Signed-off-by: J. Neuschäfer --- linux-user/strace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/linux-user/strace.c b/linux-user/strace.c index c3eb3a2706a93fdcaf693b3413b13921a3c97e8e..93e8c73de8a4a307e6e0dfbee4c769e41e64 100644 -

Re: Lost partition tables on ide-hd + ahci drive

On 02/02/2023 12:08, Fiona Ebner wrote: Hi, over the years we've got 1-2 dozen reports[0] about suddenly missing/corrupted MBR/partition tables. The issue seems to be very rare and there was no success in trying to reproduce it yet. I'm asking here in the hope that somebody has seen something sim

[PATCH v2 2/2] vhost: release virtqueue objects in error path

From: Prasad Pandit vhost_dev_start function does not release virtqueue objects when event_notifier_init() function fails. Release virtqueue objects and log a message about function failure. Signed-off-by: Prasad Pandit --- hw/virtio/vhost.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion

[PATCH v2 1/2] vhost: release memory_listener object in error path

From: Prasad Pandit vhost_dev_start function does not release memory_listener object in case of an error. This may crash the guest when vhost is unable to set memory table: stack trace of thread 125653: Program terminated with signal SIGSEGV, Segmentation fault #0 memory_listener_register

[PATCH v2 0/2] vhost: release memory objects in an error path

From: Prasad Pandit Hi, vhost_dev_start function does not release memory objects in case of an error. These couple of patches fix this glitch. Thank you. --- Prasad Pandit (2): vhost: release memory_listener object in error path vhost: release virtqueue objects in error path hw/virtio/vho

[PATCH v1] vhost: release memory objects in error path

From: Prasad Pandit vhost_dev_start function does not release memory objects in case of an error. This may crash the guest with: stack trace of thread 125653: Program terminated with signal SIGSEGV, Segmentation fault #0 memory_listener_register (qemu-kvm + 0x6cda0f) #1 vhost_dev_start

[PATCH] vhost: release memory objects in error path

From: Prasad Pandit vhost_dev_start function does not release memory objects in case of an error. This may crash the guest with: stack trace of thread 125653: Program terminated with signal SIGSEGV, Segmentation fault #0 memory_listener_register (qemu-kvm + 0x6cda0f) #1 vhost_dev_start

Re: [RFC] hw/net/vmxnet3: allow VMXNET3_MAX_MTU itself as a value

allocate and/or access packet buffer(s)   so above check might work, but still it does not seem clean, ie. it may lead to some confusion. * Nonetheless, Jason has acked it, so that's good. Thank you. ---   -P J P http://feedmug.com

Re: [PATCH] net: vmxnet3: validate configuration values during activate (CVE-2021-20203)

On Monday, 18 October, 2021, 12:20:55 pm IST, Thomas Huth wrote: On 30/01/2021 14.16, P J P wrote: >> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c >> index eff299f629..4a910ca971 100644 >> --- a/hw/net/vmxnet3.c >> +++ b/hw/net/vmxnet3.c >> @@

Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API

On Tuesday, 14 September, 2021, 07:00:27 pm IST, P J P wrote: >* Thanks so much for restarting this thread. I've been at it intermittently >last few > months, thinking about how could we annotate the source/module objects. > > -> [*] https://lists.gnu.org/archive/

Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API

;struct type' field.    * Does adding a field to struct type (ex. DeviceClass) scale to all objects/modules/backends etc?   Does it have any limitations to include/cover other sources/objects? * I'd really appreciate any feedback/inputs/suggestions you may have. Thank you. ---   -P J P http://feedmug.com

Re: [PATCH] hw/rdma: Fix possible mremap overflow in the pvrdma device (CVE-2021-3582)

", nchunks, >length); >+        return NULL; >+    } >+ >    dir = rdma_pci_dma_map(pdev, pdir_dma, TARGET_PAGE_SIZE); >    if (!dir) { >        rdma_error_report("Failed to map to page directory"); > Looks okay. Reviewed-by: Prasad J Pandit Thank you. ---   -P J P http://feedmug.com

Re: [PATCH] ui/spice-display: check NULL pointer in interface_release_resource()

, | SimpleSpiceCursor *cursor; | QXLCommandExt *ext; | | +if (!rext.info) { | +return; | +} | + | ext = (void *)(intptr_t)(rext.info->id); | switch (ext->cmd.type) { | case QXL_CMD_DRAW: Looks okay. Reviewed-by: Prasad J Pandit Thank you. -- - P J P 8685 545

Re: [PATCH] fdc: check drive block device before usage (CVE-2021-20196)

h the 3 fdc issues we've found open and try to fix them together as one series. Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH v2] fdc: check null block pointer before r/w data transfer

's easier for downstream users to pick them. Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH] fdc: check drive block device before usage (CVE-2021-20196)

I sent earlier about the qtest reproducer not correlating to | this patch -- it does, I was experiencing an unrelated crash. * Okay. | On 5/17/21 7:12 AM, P J P wrote: | > Do we need a revised patch[-series] including a qtest? OR it can be done at | > merge time? | | If you have the ti

Re: [PATCH] fdc: check drive block device before usage (CVE-2021-20196)

+-- On Sat, 15 May 2021, Philippe Mathieu-Daudé wrote --+ | This patch misses the qtest companion with the reproducer | provided by Alexander. Do we need a revised patch[-series] including a qtest? OR it can be done at merge time? Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A

Re: [PATCH 1/7] vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info

+-- On Wed, 5 May 2021, Li Qiang wrote --+ | P J P 于2021年5月5日周三 下午3:24写道： | > - vg_ctrl_response(g, cmd, &resp.hdr, sizeof(resp)); | > + vg_ctrl_response(g, cmd, &resp.hdr, sizeof(resp.hdr)); | > | > * While memset(3) is okay, should it also send header(hdr) size as 

Re: [PATCH 6/7] vhost-user-gpu: fix memory leak in 'virgl_resource_attach_backing'

); | +} | } * Similar to earlier, hw/display/virtio-gpu-3d.c:virgl_resource_attach_backing() calls 'virtio_gpu_cleanup_mapping_iov' * should it be same for vhost-user-gpu? Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH 7/7] vhost-user-gpu: fix OOB write in 'virgl_cmd_get_capset'

_malloc0(sizeof(*resp) + max_size); | | resp->hdr.type = VIRTIO_GPU_RESP_OK_CAPSET; * Looks okay. Reviewed-by: Prasad J Pandit Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH 5/7] vhost-user-gpu: fix memory leak in 'virgl_cmd_resource_unref'

irgl_cmd_resource_unref'? if (res_iovs != NULL && num_iovs != 0) { virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs); } Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH 4/7] vhost-user-gpu: fix memory link while calling 'vg_resource_unref'

g_free(res); | * Looks good. Reviewed-by: Prasad J Pandit Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH 3/7] vhost-user-gpu: fix memory leak in vg_resource_attach_backing

e done by 'virtio_gpu_find_resource()' before returning 'res' ? ie. if 'res->iov' is being used, then it's similar case as 'illegal resource specified %d'. Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH 2/7] vhost-user-gpu: fix resource leak in 'vg_resource_create_2d'

failed %d %d %d", | __func__, c2d.resource_id, c2d.width, c2d.height); | g_free(res); | +vugbm_buffer_destroy(&res->buffer); | cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY; | return; | } * Looks good. Reviewed-by: Prasad J Pandit Thank y

Re: [PATCH 1/7] vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info

hdr) size as 'resp_len'? Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH] spapr: Modify ibm, get-config-addr-info2 to set DEVNUM in PE config address.

On 2021-04-30 11:53:24 Fri, Oliver O'Halloran wrote: > On Thu, Apr 29, 2021 at 7:02 PM Mahesh J Salgaonkar > wrote: > > > > On 2021-04-28 22:33:45 Wed, Oliver O'Halloran wrote: > > > On Tue, Apr 27, 2021 at 9:56 PM Mahesh Salgaonkar > > > wrote: &g

Re: [PATCH] spapr: Modify ibm, get-config-addr-info2 to set DEVNUM in PE config address.

On 2021-04-30 07:52:58 Fri, Daniel Henrique Barboza wrote: > > > On 4/29/21 6:02 AM, Mahesh J Salgaonkar wrote: > > On 2021-04-28 22:33:45 Wed, Oliver O'Halloran wrote: > > > On Tue, Apr 27, 2021 at 9:56 PM Mahesh Salgaonkar > > > wrote: > > > &g

Re: [PATCH] spapr: Modify ibm, get-config-addr-info2 to set DEVNUM in PE config address.

of card 1's PE then the guest will see an unexpected > reset of card 2 as well. From the hypervisor's point of view the two > are in the same PE so this is a legitimate thing to do, but due to > this patch the guest doesn't know that. Agree. I realize my fix is not correctly handling this. The current code under ibm,set-eeh-option is checking for individual PCI device presence. Better fix should be to check if there is any PCI device (vfio-pci) present under specified bus and enable the EEH if found. And no change in return value of get-config-addr-info2. What do you say ? -- Mahesh J Salgaonkar

Re: [PATCH] MAINTAINERS: add/replace backups for some s390 areas

Pasic -M: Pierre Morel +M: Jason Herne Acked-by: Jason J. Herne -- -- Jason J. Herne (jjhe...@linux.ibm.com)

[Bug 1909247] Re: QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c

On Wednesday, 17 March, 2021, 10:26:36 pm IST, Cheolwoo Myung wrote: > Hello PJP, Mauro > > Of course. you can post the details with our reproducers. > I'm glad it helped you. > > Thank you. > - Cheolwoo Myung > 2021년 3월 17일 (수) 오후 10:30, P J P 님이 작성: > >

Re: [QEMU-SECURITY] [PATCH V4 00/10] Detect reentrant RX casued by loopback

Hello all, Just to note: * Let's use list to review non-public/embargoed patch(es) only. * If patch(es) is being reviewed publicly on list,   CC'ing list does not help much. Thank you. ---   -P J P http://feedmug.com

Re: [PATCH V2 7/7] rtl8193: switch to use qemu_receive_packet() for loopback

3: switch to use qemu_receive_packet() for loopback * Patch 'V2' need not be here. Thank you. -- - P J P 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [QEMU-SECURITY] [PATCH 1/6] net: introduce qemu_receive_packet()

Hello Alex, On Thursday, 25 February, 2021, 10:00:33 pm IST, Alexander Bulekov wrote:  On 210225 1128, Alexander Bulekov wrote: > On 210225 1931, P J P wrote: > > +-- On Wed, 24 Feb 2021, Philippe Mathieu-Daudé wrote --+ > > | On 2/24/21 2:17 PM, Jason Wang wrote: > > | &

Re: [PATCH 1/6] net: introduce qemu_receive_packet()

e releases? (it seems to be within the KVM | >> devices boundary). | > | > | > That's the plan. I discussed this with Prasad before and he promise to | > ask CVE for this. 'CVE-2021-3416' is assigned to this issue by Red Hat Inc. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH] net: eepro100: validate various address values

*/ | +    s->busy = false; |  } | |  static void eepro100_cu_command(EEPRO100State * s, uint8_t val) Please see: -> https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Feepro100_stackoverflow1 * It does not seem to address above case. Thank you. -- Prasad J Pandit / Red Hat Product S

Re: [PATCH] net: e1000: check transmit descriptor field values

. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH] net: eepro100: validate various address values

s 16bit value with non-zero(0) base address. ie. maximum offset could be about ~4K for 16byte command block IIUC. I'm not sure if segmented addressing mode is supported. * I'd appreciate if you could suggest a right way to fix it OR propose/post another patch. I'm okay eit

[PATCH] net: eepro100: validate various address values

From: Prasad J Pandit While processing controller commands, eepro100 emulator gets command unit(CU) base address OR receive unit (RU) base address OR command block (CB) address from guest. If these values are not checked, it may lead to an infinite loop kind of issues. Add checks to avoid it

Re: [PATCH] net: e1000: check transmit descriptor field values

Hello Jason, +-- On Thu, 18 Feb 2021, Jason Wang wrote --+ | On 2021/2/10 下午10:52, P J P wrote: | > From: Prasad J Pandit | > | > While processing transmit (tx) descriptors in process_tx_desc() | > various descriptor fields are not checked properly. This may lead | > to inf

[PATCH] net: e1000: check transmit descriptor field values

From: Prasad J Pandit While processing transmit (tx) descriptors in process_tx_desc() various descriptor fields are not checked properly. This may lead to infinite loop like issue. Add checks to avoid them. Reported-by: Alexander Bulekov Reported-by: Cheolwoo Myung Reported-by: Ruhr

Re: [QEMU-SECURITY] [PATCH] hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register

uot; >(the default is 'on', and turning it off is an odd thing to do). > 'CVE-2021-20221' assigned by Red Hat Inc.   -> https://bugs.launchpad.net/qemu/+bug/1914353/comments/3 Thank you. ---   -P J P http://feedmug.com

Re: [PULL 00/21] target-arm queue

-2021-20221' assigned by Red Hat Inc. -> https://bugs.launchpad.net/qemu/+bug/1914353/comments/3 Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

[Bug 1914353] Re: QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID

'CVE-2021-20221' assigned by Red Hat Inc. ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-20221 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914353 Title: QEMU: aarch64: :GIC:

[Bug 1914353] Re: QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID

CVE requested. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914353 Title: QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID Status in QEMU: New Bug description: Via [qemu-security]

[Bug 1914353] [NEW] QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID

*** This bug is a security vulnerability *** Public security bug reported: Via [qemu-security] list +-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+ | On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote: | > Per the ARM Generic Interrupt Controller Architecture specification | > (document

[Bug 1914353] Re: QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID

Upstream patch: -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00709.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914353 Title: QEMU: aarch64: :GIC: out-of-bounds access via i

[Bug 1914236] Re: QEMU: scsi: use-after-free in mptsas_process_scsi_io_request() of mptsas1068 emulator

Upstream patch -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00488.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914236 Title: QEMU: scsi: use-after-free in mptsas_process_scs

[Bug 1914236] Re: QEMU: scsi: use-after-free in mptsas_process_scsi_io_request() of mptsas1068 emulator

** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914236 Title: QEMU: scsi: use-after-free in mptsas_process_scsi_io_request() of

[PATCH] scsi: mptsas: dequeue request object in case of an error (CVE-2021-3392)

From: Prasad J Pandit While processing SCSI i/o requests in mptsas_process_scsi_io_request(), the Megaraid emulator appends new MPTSASRequest object 'req' to the 's->pending' queue. In case of an error, this same object gets dequeued in mptsas_free_request() only if SCSIRe

Re: [QEMU-SECURITY] [PATCH] hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register

> | >  [R +0.278293] writel 0x8000f00 0xff4affb0 > | >  ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for > type 'uint8_t [16][8]' > | >  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior > ../hw/intc/arm_gic.c:1498:13 > | >  > | > Cc: qemu-sta...@nongnu.org > | > Fixes: 9ee6e8bb853 ("ARMv7 support.") > | > | > --- > | > Isnt it worth a CVE to help distributions track backports? > | > --- Thank you for reporting this issue. Will process further. Thank you. ---   -P J P http://feedmug.com

Re: [PATCH 0/9] Fix some style problems in net

ping？This patch set about code style problem in net receives no replies. Did I miss any response? The link follows: http://patchwork.ozlabs.org/project/qemu-devel/cover/20201222082340.67405-1-zhangha...@huawei.com/

Re: [PATCH 0/4] Fix some style problems in qobject

ping？This patch set about code style problem in qobject receives no replies. Did I miss any response? The link follows: http://patchwork.ozlabs.org/project/qemu-devel/cover/20201228071129.24563-1-zhangha...@huawei.com/

Re: [PATCH] hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register

9ee6e8bb853 ("ARMv7 support.") | > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916 | > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917 | | > --- | > Isnt it worth a CVE to help distributions track backports? | > --- * Please send such report(s) to 'qemu-security' list to be triaged as potential security ones. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

[Bug 1890152] Re: malloc 0xff0000030 bytes with vmxnet3

*** This bug is a duplicate of bug 1913873 *** https://bugs.launchpad.net/bugs/1913873 ** This bug has been marked a duplicate of bug 1913873 QEMU: net: vmxnet: integer overflow may crash guest -- You received this bug notification because you are a member of qemu- devel-ml, which is subs

[Bug 1913873] Re: QEMU: net: vmxnet: integer overflow may crash guest

p;s->txq_descr[i].comp_ring); @@ -1524,6 +1531,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) /* RX rings */ pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.rxRingBasePA[j]); size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.rxRingS

Re: [PATCH] fdc: check drive block device before usage (CVE-2021-20196)

+-- On Sat, 23 Jan 2021, P J P wrote --+ | From: Prasad J Pandit | | While processing ioport command in 'fdctrl_write_dor', device | controller may select a drive which is not initialised with a | block device. This may result in a NULL pointer dereference. | Add checks to avoid it.

[Bug 1913873] Re: QEMU: net: vmxnet: integer overflow may crash guest

DUMP(VMW_CFPRN, "TXC", i, &s->txq_descr[i].comp_ring); @@ -1524,6 +1531,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) /* RX rings */ pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.rxRingBasePA[j]);

[PATCH] net: vmxnet3: validate configuration values during activate (CVE-2021-20203)

From: Prasad J Pandit While activating device in vmxnet3_acticate_device(), it does not validate guest supplied configuration values against predefined minimum - maximum limits. This may lead to integer overflow or OOB access issues. Add checks to avoid it. Fixes: CVE-2021-20203 Buglink: https

[Bug 1912780] Re: QEMU: Null Pointer Failure in fdctrl_read() in hw/block/fdc.c

Upstream patch: -> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg05986.html ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.n

[PATCH] fdc: check drive block device before usage (CVE-2021-20196)

From: Prasad J Pandit While processing ioport command in 'fdctrl_write_dor', device controller may select a drive which is not initialised with a block device. This may result in a NULL pointer dereference. Add checks to avoid it. Fixes: CVE-2021-20196 Reported-by: Gaoning Pan Bugl

Re: About 'qemu-security' list subscription process

art a thread on the -sec list for pending requests. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [Qemu-devel] [PATCH v2 07/11] chardev: Let IOReadHandler use unsigned type

dn't realise it's not merged. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

[PATCH v2] ide: set an upper limit to nb_sectors

From: Prasad J Pandit Set an upper limit to number of sectors on an IDE disk media. This is to ensure that logical block addresses (LBA) and nb_sector arguments remain within INT_MAX range. Suggested-by: Paolo Bonzini Signed-off-by: Prasad J Pandit --- hw/ide/core.c | 27

[PATCH] ide: set an upper limit to nb_sectors

From: Prasad J Pandit Set an upper limit to number of sectors on an IDE disk media. This is to ensure that logical block addresses (LBA) and nb_sector arguments remain within INT_MAX range. Suggested-by: Paolo Bonzini Signed-off-by: Prasad J Pandit --- hw/ide/core.c | 23

Re: [PATCH v2] ide: atapi: check logical block address and read size (CVE-2020-29443)

+-- On Mon, 18 Jan 2021, Paolo Bonzini wrote --+ | On 18/01/21 13:29, P J P wrote: | > +s->nb_sectors = nb_sectors & (uint64_t)INT_MAX << 2; | > if (kind == IDE_CD) { | > +s->nb_sectors &= (uint64_t)INT_MAX << 2; | | Not an &, but rather

Re: [PATCH v2] ide: atapi: check logical block address and read size (CVE-2020-29443)

kind, s->smart_errors = 0; s->smart_selftest_count = 0; if (kind == IDE_CD) { +s->nb_sectors &= (uint64_t)INT_MAX << 2; blk_set_dev_ops(blk, &ide_cd_block_ops, s); blk_set_guest_block_size(blk, 2048); === * Isn't 4TB limit more for I

[PATCH v3] ide: atapi: check logical block address and read size (CVE-2020-29443)

From: Prasad J Pandit While processing ATAPI cmd_read/cmd_read_cd commands, Logical Block Address (LBA) maybe invalid OR closer to the last block, leading to an OOB access issues. Add range check to avoid it. Fixes: CVE-2020-29443 Reported-by: Wenxiang Qian Suggested-by: Paolo Bonzini

Re: [PATCH v2] ide: atapi: check logical block address and read size (CVE-2020-29443)

MAX | << 2, just to be super safe. To confirm: * (uint64_t)INT_MAX << 2 is => 8589934588 ~= 8.5G sectors ? Media size would be: 8.5G * 512B(sector) => ~4TB 8.5G * 4096B(sector) => ~32TB * We are limiting IDE media size to ~4TB/~32TB ? Thank you. -- P

[PATCH v2] ide: atapi: check logical block address and read size (CVE-2020-29443)

From: Prasad J Pandit While processing ATAPI cmd_read/cmd_read_cd commands, Logical Block Address (LBA) maybe invalid OR closer to the last block, leading to an OOB access issues. Add range check to avoid it. Fixes: CVE-2020-29443 Reported-by: Wenxiang Qian Fix-suggested-by: Paolo Bonzini

Re: [PATCH v2 1/1] security-process: update process information

+-- On Thu, 14 Jan 2021, Philippe Mathieu-Daudé wrote --+ | What is the status of this, is something missing? -> https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04469.html It is up and running.^^ Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C

[Bug 1911666] Re: ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability

'CVE-2021-20181' is assigned to this issue by Red Hat Inc. ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-20181 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1911666 Title: ZDI-

About 'qemu-security' list subscription process

requests? Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

[Bug 1911666] Re: ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability

Requesting a CVE... ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1911666 Title: ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU

Re: [PATCH 0/9] Fix some style problems in net

ping? This patch set is submmitted a month ago, and have received no replies. Did I miss any replies? The link follows: http://patchwork.ozlabs.org/project/qemu-devel/cover/20201222082340.67405-1-zhangha...@huawei.com/

Re: [PATCH 0/4] Fix some style problems in qobject

ping? This patch set was submitted two weeks ago,and 2 of patches ([1/4], [4/4]) has been reviewd. Whose tree should it go via? Other patches receive no replies. Did I miss any response? The link follows: http://patchwork.ozlabs.org/project/qemu-devel/cover/20201228071129.24563-1-zhangha...@hua

[ANNOUNCE] qemu-security mailing list

triage process. * All members will be required to agree and adhere to the embargo rules and restrictions. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end

n range when issuing a read request | | 2) that the size of the device is sane (e.g. the number of blocks is a | positive 32-bit integer). Yes, working on a revised patch... Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [RFC PATCH-for-5.2 1/2] net: Do not accept packets bigger then NET_BUFSIZE

MTU 0xU /* 65535, same as IP_MAX_MTU*/ if (size < ETH_MIN_MTU || size > ETH_MAX_MTU) { return -1; } Should there be similar check for minimum packet size? Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

[PATCH v2 1/1] security-process: update process information

From: Prasad J Pandit We are about to introduce a qemu-security mailing list to report and triage QEMU security issues. Update the security process web page with new mailing list address and triage details. Signed-off-by: Prasad J Pandit --- contribute/security-process.md | 154

[PATCH v2 0/1] security-process: update with mailing list details

From: Prasad J Pandit Hello, * After upstream discussions and considering various options like LaunchPad bugs, GitLab issues etc. -> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg04266.html -> https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg00059.html

Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end

+-- On Wed, 2 Dec 2020, Philippe Mathieu-Daudé wrote --+ | a fair part is to ask the reporter to attach its reproducer to the private | BZ, Yes, reporters sharing/releasing it is best. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050

Re: [PATCH v1 1/1] security-process: update process information

choose either LaunchPad or GitLab issues. * OR is it better to have both? ie. file a public tracker anywhere as per ones convenience? * One GitLab is good I think. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH v1 1/1] security-process: update process information

Same here, will fix it. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH v1 1/1] security-process: update process information

2 weeks, however, longer |embargoes can be negotiated if the severity of the issues requires it." Okay, will add above changes. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH v1 1/1] security-process: update process information

| |^^^ You can remove that, as now covered by bullet 0). Okay, will do. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end

That way multiple reproducers for the same issue can be held together. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: [PATCH v1 1/1] security-process: update process information

Hello Konrad, all +-- On Tue, 1 Dec 2020, Konrad Rzeszutek Wilk wrote --+ | On Mon, Nov 30, 2020 at 07:19:07PM +0530, P J P wrote: | > We are about to introduce a qemu-security mailing list to report | > and triage QEMU security issues. | > Update the QEMU security process web page

Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end

x27;t heed | the advice though; I'm calling you out this time because it's especially clear | that you didn't do these steps and because the result is especially wrong. * While I understand and agree that having qtests is greatly helpful, I could not get to it due to time/cycles

[PATCH v1 1/1] security-process: update process information

From: Prasad J Pandit We are about to introduce a qemu-security mailing list to report and triage QEMU security issues. Update the QEMU security process web page with new mailing list and triage details. Signed-off-by: Prasad J Pandit --- contribute/security-process.md | 134

[PATCH v1 0/1] security-process: update with mailing list details

From: Prasad J Pandit Hello, * After upstream discussions and considering various options like LaunchPad bugs, GitLab issues etc. -> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg04266.html -> https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg00059.html

Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end

+-- On Wed, 18 Nov 2020, P J P wrote --+ | During data transfer via packet command in 'ide_atapi_cmd_reply_end' | 's->io_buffer_index' could exceed the 's->io_buffer' length, leading | to OOB access issue. Add check to avoid it. | ... | #9 ahci_pio_t

  1   2   3   4   5   6   7   8   9   10   >