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
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
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
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
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
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
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
>> @@
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/html/
/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
", 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
,
| 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
c 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
ier for downstream users to pick them.
Thank you.
--
- P J P
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
t 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 time to write a qtest reproduc
+-- 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
+-- On Wed, 5 May 2021, Li Qiang wrote --+
| P J P 于2021年5月5日周三 下午3:24写道：
| > - vg_ctrl_response(g, cmd, , sizeof(resp));
| > + vg_ctrl_response(g, cmd, , sizeof(resp.hdr));
| >
| > * While memset(3) is okay, should it also send header(hdr) size as
'resp_len'?
|
| I do
);
| +}
| }
* 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
r.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
'?
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
good.
Reviewed-by: Prasad J Pandit
Thank you.
--
- P J P
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
)'
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
%d %d",
| __func__, c2d.resource_id, c2d.width, c2d.height);
| g_free(res);
| +vugbm_buffer_destroy(>buffer);
| cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
| return;
| }
* Looks good.
Reviewed-by: Prasad J Pandit
Thank you.
--
- P J P
868
J P
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
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 님이 작성:
>
>On Mo
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
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
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:
> > | &
+-- On Wed, 24 Feb 2021, Philippe Mathieu-Daudé wrote --+
| On 2/24/21 2:17 PM, Jason Wang wrote:
| > On 2021/2/24 6:11 下午, Philippe Mathieu-Daudé wrote:
| >> IIUC the guest could trigger an infinite loop and brick the emulated
| >> device model. Likely exhausting the stack, so either SEGV by
Hello Stefan,
+-- On Fri, 19 Feb 2021, Stefan Weil wrote --+
| If there are no recursions in normal use, the following patch should work:
|
| diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
| index 16e95ef9cc..2474cf3dc2 100644
| --- a/hw/net/eepro100.c
| +++ b/hw/net/eepro100.c
| @@ -279,6
+-- On Thu, 18 Feb 2021, Alexander Bulekov wrote --+
| Is this a DMA re-entracy/stack-overflow issue? IIRC the plan was to have
| some sort of wider fix for these issues. There are bunch of these reports
| floating around at this point, I believe.
* It is similar to the eepro100 one.
Thank
Hello Alex, Stefan, all
+-- On Thu, 18 Feb 2021, Alexander Bulekov wrote --+
| Maybe the infinite loop mentioned in the commit message is actually a DMA
| recursion issue? I'm providing a reproducer for a DMA re-entracy issue
| below. With this patch applied, the reproducer triggers the
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.
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
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:
p=off"
>(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
+-- On Wed, 3 Feb 2021, Philippe Mathieu-Daudé wrote --+
| FYI Prasad mentioned a CVE was requested:
| https://www.mail-archive.com/qemu-devel@nongnu.org/msg778659.html
|
| As you said it is an odd configuration, I am not sure it is worth
| to wait for the CVE number to add it to the commit
'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:
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
*** 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
| >
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
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
** 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
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 SCSIRequest object
tel 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
+-- 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 "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
| > not 10:
| >
| > - Table 4-21
*** 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
Yes, from the trace looks same.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913873
Title:
QEMU: net: vmxnet: integer overflow may crash guest
Status in QEMU:
New
Bug description:
*
+-- 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.
|
| Fixes
** 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/1913873
Title:
QEMU: net: vmxnet: integer overflow may crash guest
Status in
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:
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.
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
Buglink:
+-- On Fri, 15 Jan 2021, Daniel P. Berrangé wrote --+
| IOW ideally there should be some web of trust whereby some existing
| member(s) knows the person/entity who is requesting acces. Other cases would
| have to be evaluated case-by-case basis.
* True, sounds reasonable. I'll probably start a
+-- On Fri, 22 Jan 2021, Richard Purdie wrote --+
| If so can anyone point me at that change?
|
| I ask since CVE-2018-18438 is marked as affecting all qemu versions
| (https://nvd.nist.gov/vuln/detail/CVE-2018-18438).
|
| If it was fixed, the version mask could be updated. If the fix wasn't
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
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
+-- 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
+-- On Mon, 18 Jan 2021, Paolo Bonzini wrote --+
| s->nb_sectors is in units of 512B, so the limit would be 4TB. The purpose
| is to limit the lba and nb_sectors arguments (which are in 2048B units) of
| ide_atapi_cmd_read_{dma,pio} to INT_MAX.
* If it's for IDE_CD type, does the patch below
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
+-- On Mon, 18 Jan 2021, Paolo Bonzini wrote --+
| Thank you! This looks great.
| With the small spacing fix suggested by checkpatch,
| Reviewed-by: Paolo Bonzini
Thank you. Will send patch v3 with space typo fix.
| You may add a small patch on top to clamp s->nb_sectors at (uint64_t)INT_MAX
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
+-- 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 C6EB
'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:
Hello,
* We have received quite a few subscription requests for the 'qemu-security'
list in the last few weeks. Majority of them are rejected because we could
not identify the user from merely their email-id.
* I have requested them to send a subscription request email with a 'Self
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
Hello,
* QEMU project has set-up a dedicated mailing list to receive and triage all
its security issues.
Please see:
-> https://www.qemu.org/contribute/security-process/
-> https://lists.nongnu.org/mailman/listinfo/qemu-security
* If you are a security researcher OR think you've
+-- On Fri, 11 Dec 2020, Paolo Bonzini wrote --+
| This is not the root cause. These are the last steps before bad things
| happen; the root cause is what _led_ to those last steps. In this case, the
| root cause is that a read request with s->lba == -1 is mistaken for a
| non-read. Read
+-- On Fri, 27 Nov 2020, Philippe Mathieu-Daudé wrote --+
| Do not allow qemu_send_packet*() and qemu_net_queue_send()
| functions to accept packets bigger then NET_BUFSIZE.
|
| We have to put a limit somewhere. NET_BUFSIZE is defined as:
| /* Maximum GSO packet size (64k) plus plenty of room
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
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
We are
+-- 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
+-- On Wed, 2 Dec 2020, Daniel P. Berrangé wrote --+
| > +- If issue is found to be less severe, an upstream public bug (or an
| > + issue) will be created immediately.
|
| No need to repeat "or an issue". I think it would read more clearly as
|
|- If the severity of the issue is
Hello Dan, Stefano,
+-- On Wed, 2 Dec 2020, Stefano Stabellini wrote --+
| On Wed, 2 Dec 2020, Daniel P. Berrangé wrote:
| > > + any third parties, including Xen Security Project, without your prior
| > > + permission.
| >
| > Why this explicit note about the Xen project ? What if we decide
Hello Dan,
+-- On Wed, 2 Dec 2020, Daniel P. Berrangé wrote --+
| > +- If issue is found to be less severe, an upstream public bug (or an
| > + issue) will be created immediately.
|
| No need to repeat "or an issue". I think it would read more clearly as
|
|- If the severity of
+-- On Wed, 2 Dec 2020, Philippe Mathieu-Daudé wrote --+
| Maybe:
|
| 0) **Acknowledge reception**
|- A non-automated response email is sent to acknowledge the
| reception of the request.
| This is the starting date for the maximum **60 days** required
| to
Hi,
[doing a combined reply]
+-- On Tue, 1 Dec 2020, Philippe Mathieu-Daudé wrote --+
| Is it possible to release the reproducer to the community, so we can work on
| a fix and test it?
* No, we can not release/share reproducers on a public list.
* We can request reporters to do so by
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
Hello Paolo,
+-- On Tue, 1 Dec 2020, Paolo Bonzini wrote --+
| 1) Obviously this condition was not in the mind of whoever wrote the code.
| For this reason the first thing to understand if how the bug came to happen,
| which precondition was not respected. Your backtraces shows that you came
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
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
We are
+-- 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_transfer ../hw/ide/ahci.c:1383
+-- On Tue, 15 Sep 2020, P J P wrote --+
| +-- On Tue, 11 Aug 2020, P J P wrote --+
| | * This series asserts that MemoryRegionOps objects define read/write
| | callback methods. Thus avoids potential NULL pointer dereference.
| | ex. ->
https://git.qemu.org/?p=qemu.git;a=commi
Hello Darren, all
+-- On Tue, 24 Nov 2020, Darren Kenny wrote --+
| I always understood triage to be the initial steps in assessing a bug:
|
| - determining if it is a security bug, in this case
| - then deciding on the severity of it
|
| I would not expect triage to include seeing it through
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 | 105
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
We are
From: Prasad J Pandit
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_transfer ../hw/ide/ahci.c:1383
#10 ide_transfer_start_norecurse
Hello Dan, Stefan,
+-- On Tue, 17 Nov 2020, Daniel P. Berrangé wrote --+
| On Tue, Nov 17, 2020 at 04:19:42PM +, Stefan Hajnoczi wrote:
| > Dan and I tried out confidential issues and unfortunately it is
| > currently too limited for our workflow.
| >
| > It is not possible to add
From: Prasad J Pandit
While receiving packets via e1000e_write_packet_to_guest() routine,
'desc_offset' is advanced only when RX descriptor is processed. And
RX descriptor is not processed if it has NULL buffer address.
This may lead to an infinite loop condition. Increament 'desc_offset'
to
+-- On Thu, 22 Oct 2020, Daniel P. Berrangé wrote --+
| On Thu, Oct 22, 2020 at 12:24:16PM -0400, Alexander Bulekov wrote:
| > > Once [2] lands upstream, we should see a significant uptick in oss-fuzz
| > > reports, and I hope that we can develop a process to ensure these bugs
| > > are
+-- On Tue, 20 Oct 2020, P J P wrote --+
| +-- On Fri, 16 Oct 2020, P J P wrote --+
| | * So ie. we need to:
| |
| | 1. Create/setup a regular non-encrypted 'qemu-security' list.
| |
| | 2. Invite representatives from user/downstream communities to subscribe
to
| | it.
| |
| | 3
From: Prasad J Pandit
The source and destination x,y display parameters in ati_2d_blt()
may run off the vga limits if either of s->regs.[src|dst]_[xy] is
zero. Check the parameter values to avoid potential crash.
Reported-by: Gaoning Pan
Signed-off-by: Prasad J Pandit
---
hw/display/ati_2d.c
+-- On Wed, 21 Oct 2020, Philippe Mathieu-Daudé wrote --+
| $ git grep qemu_log\( | wc -l
| 661
|
| This function seems used mostly by very old code.
| It is declared in "qemu/log-for-trace.h" which looks like an internal API.
|
| Should we add a checkpatch rule to refuse new uses of qemu_log()?
+-- On Wed, 21 Oct 2020, Jason Wang wrote --+
| It should not be a guest error, since guest is allowed to send a packet
| other than IPV4(6).
* Ah...sigh! :(
* I very hesitantly used guest_error mask, since it was g_assert-ing before.
To me both guest_error and log_unimp seem mismatching.
+-- On Tue, 20 Oct 2020, Peter Maydell wrote --+
| If the guest must have done something wrong to get us here:
| use LOG_GUEST_ERROR
+-- On Tue, 20 Oct 2020, Philippe Mathieu-Daudé wrote --+
| Not sure why you choose decimal, the usual format is "0x%04"PRIx16.
Sent patch v3 with above updates.
From: Prasad J Pandit
eth_get_gso_type() routine returns segmentation offload type based on
L3 protocol type. It calls g_assert_not_reached if L3 protocol is
unknown, making the following return statement unreachable. Remove the
g_assert call, it maybe triggered by a guest user.
Reported-by:
+-- On Fri, 16 Oct 2020, P J P wrote --+
| * So ie. we need to:
|
| 1. Create/setup a regular non-encrypted 'qemu-security' list.
|
| 2. Invite representatives from user/downstream communities to subscribe to
| it.
|
| 3. Collect & store their PGP public keys. Also create a
From: Prasad J Pandit
eth_get_gso_type() routine returns segmentation offload type based on
L3 protocol type. It calls g_assert_not_reached if L3 protocol is
unknown, making the following return statement unreachable. Remove the
g_assert call, as it maybe triggered by a guest user.
Reported-by:
+-- On Tue, 20 Oct 2020, BALATON Zoltan wrote --+
| The card has 32 bit registers with values in them interpreted differently for
| different regs. For dst_x|y lower 14 bits can be set and value should be
| interpreted as -8192:8191 according to docs. I've got this wrong because all
| guests I've
+-- On Tue, 20 Oct 2020, Philippe Mathieu-Daudé wrote --+
| Maybe LOG_UNIMP with useful fields, so when user send bug report we directly
| know what has to be implemented.
qemu_log("Probably not GSO frame, unknown L3 protocol: %hd\n", l3_proto);
Maybe just qemu_log()? LOG_UNIMP seems
From: Prasad J Pandit
eth_get_gso_type() routine returns segmentation offload type to use
based on L3 protocol type. It calls g_assert_not_reached if L3
protocol is unknown, making the following return statement unreachable.
Remove the g_assert call, as it maybe triggered by a guest user.
1 - 100 of 912 matches
Mail list logo
