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]
'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:
+-- 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 (which
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
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-University
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: Gao
+-- 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.
+-- 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. Be
+-- 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()?
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, 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
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 t
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
+-- 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 suf
+-- 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 DE8
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 a
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 ++
+-- 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 fo
+-- 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 requ
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 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
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 assert
+-- 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 you.
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
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 a
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 +
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 t
+-- 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
+-- 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
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 a
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 +
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
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
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 thei
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 f
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,
* 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
Intro
'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-
+-- 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 27
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
Sign
+-- 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
Suggested-by: Paolo Bonzini
Reviewed
+-- 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 lo
+-- 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
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 -
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
On ppc hosts, hypervisor shares following system attributes
- /proc/device-tree/system-id
- /proc/device-tree/model
with a guest. This could lead to information leakage and misuse.[*]
Add machine attributes to control such system information exposure
to a guest.
[*] h
+-- On Wed, 13 Feb 2019, David Gibson wrote --+
| > +
| > +object_class_property_add_str(oc, "host-serial",
| > +machine_get_host_serial, machine_set_host_serial,
| > +&error_abort);
| > +object_class_property_set_description(oc, "host-serial",
| > +"Set host's syste
From: Prasad J Pandit
On ppc hosts, hypervisor shares following system attributes
- /proc/device-tree/system-id
- /proc/device-tree/model
with a guest. This could lead to information leakage and misuse.[*]
Add machine attributes to control such system information exposure
to a guest.
[*] h
From: Prasad J Pandit
On ppc hosts, hypervisor shares following system attributes
- /proc/device-tree/system-id
- /proc/device-tree/model
with a guest. This could lead to information leakage and misuse.[*]
Add machine attributes to control such system information exposure
to a guest.
[*] h
Hello Greg, Dan,
+-- On Mon, 18 Feb 2019, Greg Kurz wrote --+
| >>> +spapr->host_model = NULL;
| >>
| >> This isn't needed since object_initialize_with_type() already takes care
| >> of zeroing the instance for us.
| >>
| >>> +spapr->host_serial = NULL;
| >>
| >> Same here.
|
|
From: Prasad J Pandit
The interface names in qemu-bridge-helper are defined to be
of size IFNAMSIZ(=16), including the terminating null('\0') byte.
The same is applied to interface names read from 'bridge.conf'
file to form ACLs rules. If user supplied '--br=bridge' name
is not restricted to the
+-- On Fri, 28 Jun 2019, Daniel P. Berrangé wrote --+
| Can you elaborate on the way to exploit this as I'm not seeing
| any way that doesn't involve mis-configuration of the ACL
| config file data.
True, it depends on having an 'allow all' rule. If the bridge.conf had an
'allow all' rule below
+-- On Fri, 28 Jun 2019, Daniel P. Berrangé wrote --+
| Ok, so we should explicitly report an error if the user supplied bridge name
| is too long, not silently truncate it.
|
| We should also report an error if config file has too long a bridge name.
Okay, ie. report error and exit?
+-- On Fri
From: Prasad J Pandit
Move repeating error handling sequence in parse_acl_file routine
to an 'err' label.
Signed-off-by: Prasad J Pandit
---
qemu-bridge-helper.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
From: Prasad J Pandit
Hello,
Linux net_deivce defines network interface name to be of IFNAMSIZE(=16)
bytes, including the terminating null('\0') byte.
Qemu tap deivce, while invoking 'qemu-bridge-helper' tool to set up the
network bridge interface, supplies bridge name of 16 characters, thus
al
From: Prasad J Pandit
The interface name in Linux interface request struct 'ifreq'
OR in qemu-bridge-helper is defined to be of size IFNAMSIZ(=16),
including the terminating null('\0') byte.
QEMU tap device, while invoking qemu-bridge-helper, supplies bridge
name of 16 characters, restrict it to
From: Prasad J Pandit
The interface names in qemu-bridge-helper are defined to be
of size IFNAMSIZ(=16), including the terminating null('\0') byte.
The same is applied to interface names read from 'bridge.conf'
file to form ACLs rules. If user supplied '--br=bridge' name
is not restricted to the
+-- On Mon, 1 Jul 2019, Daniel P. Berrangé wrote --+
| Playing games with multiple "perfectly" sized static buffers & snprintf is
| madness. How about re-writing this method so that it just uses
| g_strdup_printf() to dynamically format the helper_cmd string.
|
| Alternatively we could get rid o
+-- On Mon, 1 Jul 2019, Daniel P. Berrangé wrote --+
| > +if (strcmp(cmd, "include") && strlen(arg) >= IFNAMSIZ) {
| > +fprintf(stderr, "name `%s' too long: %lu\n", arg, strlen(arg));
|
| strlen returns size_t, which does not match %lu - it needs %zu - we can
| ignore the non-p
From: Prasad J Pandit
Hello,
Linux net_deivce defines network interface name to be of IFNAMSIZE(=16)
bytes, including the terminating null('\0') byte.
Qemu tap deivce, while invoking 'qemu-bridge-helper' tool to set up the
network bridge interface, supplies bridge name of 16 characters, thus
al
From: Prasad J Pandit
Move repeating error handling sequence in parse_acl_file routine
to an 'err' label.
Signed-off-by: Prasad J Pandit
---
qemu-bridge-helper.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
From: Prasad J Pandit
The network interface name in Linux is defined to be of size
IFNAMSIZ(=16), including the terminating null('\0') byte.
The same is applied to interface names read from 'bridge.conf'
file to form ACL rules. If user supplied '--br=bridge' name
is not restricted to the same len
From: Prasad J Pandit
Refactor 'net_bridge_run_helper' routine to avoid buffer
formatting to prepare 'helper_cmd' and using shell to invoke
helper command. Instead directly execute helper program with
due arguments.
Signed-off-by: Prasad J Pandit
---
net/tap.c | 43 +---
Hello Li,
+-- On Mon, 1 Jul 2019, Li Qiang wrote --+
| You do two things here(avoid buffer formatting and get rid of calling
| shell), I would suggest you split these into split patch.
Both are related, 'helper_cmd' formatting was used with the shell invocation
as:
helper_cmd = "qemu-bridg
Hello Dan,
+-- On Tue, 2 Jul 2019, Daniel P. Berrangé wrote --+
| The original code was passing through to the shell to handle the case
| where the user requested
|
|-netdev bridge,helper="/path/to/helper myarg otherarg"
|
| In theory any parts could contain shell meta characters, but even
+-- On Mon, 26 Aug 2019, Samuel Thibault wrote --+
| Philippe Mathieu-Daudé, le ven. 23 août 2019 17:15:32 +0200, a ecrit:
| > > Did you make your test with commit 126c04acbabd ("Fix heap overflow in
| > > ip_reass on big packet input") applied?
| >
| > Yes, unfortunately it doesn't fix the issue.
From: Prasad J Pandit
Use unsigned type for the MegasasState fields which hold positive
numeric values.
Signed-off-by: Prasad J Pandit
---
hw/scsi/megasas.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/
From: Prasad J Pandit
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 Megas
From: Prasad J Pandit
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
Signed-off-by: Prasad J Pandit
---
hw/scsi/me
+-- 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
+-- 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;
+-- 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
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_fram
+-- 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
+-- 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
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_he
+-- 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 -fs
From: Prasad J Pandit
A guest user may set 'reply_queue_head' field of MegasasState 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.
Also check that 'index' value stays within s->frames[] bounds
through
From: Prasad J Pandit
While in megasas_handle_frame(), megasas_enqueue_frame() may
set a NULL frame into MegasasCmd object for a given 'frame_addr'
address. Add check to avoid a NULL pointer dereference issue.
Reported-by: Alexander Bulekov
Fixes: https://bugs.launchpad.net/qemu/+bug/1878259
Si
From: Prasad J Pandit
Hello,
* First patch fixes an OOB access issue which may occur when a guest user
sets 'reply_queue_head' field to a negative or large positive value,
via 'struct mfi_init_qinfo' object in megasas_init_firmware(), such that
'index' variables in megasas_lookup_frame()
From: Prasad J Pandit
Use unsigned type for the MegasasState fields which hold positive
numeric values.
Signed-off-by: Prasad J Pandit
---
hw/scsi/megasas.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/
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://
Hello Stefan, Jason,
+-- On Fri, 6 Mar 2020, Stefan Hajnoczi wrote --+
| > +static int
| > +tulip_can_receive(NetClientState *nc)
| > +{
| > +TULIPState *s = qemu_get_nic_opaque(nc);
| > +
| > +if (s->rx_frame_len || tulip_rx_stopped(s)) {
| > +return false;
| > +}
| > +
| >
+-- On Tue, 17 Mar 2020, Jason Wang wrote --+
| > +-- On Fri, 6 Mar 2020, Stefan Hajnoczi wrote --+
| > | > +static int
| > | > +tulip_can_receive(NetClientState *nc)
| > | > +{
| > | > +TULIPState *s = qemu_get_nic_opaque(nc);
| > | > +
| > | > +if (s->rx_frame_len || tulip_rx_stopped(s))
From: Prasad J Pandit
Hello,
* This series adds checks to avoid potential OOB access and infinite loop
issues while processing rx/tx data.
* Tulip tx descriptors are capped at 128 to avoid infinite loop in
tulip_xmit_list_update(), wrt Tulip kernel driver
->
https://git.kernel.org/pub/sc
From: Prasad J Pandit
Call qemu_flush_queued_packets to flush queued packets once they
are read in tulip_receive().
Suggested-by: Jason Wang
Signed-off-by: Prasad J Pandit
---
hw/net/tulip.c | 2 ++
1 file changed, 2 insertions(+)
Update v4: call qemu_flush_queued_packets()
-> https://list
From: Prasad J Pandit
Tulip network driver while copying tx/rx buffers does not check
frame size against r/w data length. This may lead to OOB buffer
access. Add check to avoid it.
Limit iterations over descriptors to avoid potential infinite
loop issue in tulip_xmit_list_update.
Reported-by: L
From: Prasad J Pandit
Define .can_receive routine to do sanity checks before receiving
packet data.
Signed-off-by: Prasad J Pandit
---
hw/net/tulip.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
Update v3: define .can_receive routine
-> https://lists.gnu.org/archive
Hello Jason,
+-- On Wed, 18 Mar 2020, Jason Wang wrote --+
| Right, so need to make sure qemu_flush_ququed_packets() was called when
| rx_frame_len is zero.
Sent patch v4, with this call. Please see when you've time.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B5
From: Prasad J Pandit
Hello,
* This series adds checks to avoid potential OOB access and infinite loop
issues while processing rx/tx data.
* Tulip tx descriptors are capped at 128 to avoid infinite loop in
tulip_xmit_list_update(), wrt Tulip kernel driver
->
https://git.kernel.org/pub/sc
From: Prasad J Pandit
Define .can_receive routine to do sanity checks before receiving
packet data.
Signed-off-by: Prasad J Pandit
---
hw/net/tulip.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
Update v3: define .can_receive routine
-> https://lists.gnu.org/archive
From: Prasad J Pandit
Tulip network driver while copying tx/rx buffers does not check
frame size against r/w data length. This may lead to OOB buffer
access. Add check to avoid it.
Limit iterations over descriptors to avoid potential infinite
loop issue in tulip_xmit_list_update.
Reported-by: L
From: Prasad J Pandit
Call qemu_flush_queued_packets to flush queued packets once they
are read in tulip_receive().
Suggested-by: Jason Wang
Signed-off-by: Prasad J Pandit
---
hw/net/tulip.c | 2 ++
1 file changed, 2 insertions(+)
Update v4: call qemu_flush_queued_packets()
-> https://list
+-- On Thu, 19 Mar 2020, Philippe Mathieu-Daudé wrote --+
| Typo "can_recieve" -> "can_receive" in subject.
Oops! Fixed it, sent revised patch v5.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Hello Darren,
+-- On Thu, 14 May 2020, Darren Kenny wrote --+
| > Update v1 -> v2: fix OOB access when index > MEGASAS_MAX_FRAMES(=2048)
| > -> https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03131.html
| >
| > diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
| > -int reply_queue
From: Prasad J Pandit
A guest user may set channel frame count via es1370_write()
such that, in es1370_transfer_audio(), total frame count
'size' is lesser than the number of frames that are processed
'cnt'.
int cnt = d->frame_cnt >> 16;
int size = d->frame_cnt & 0x;
if (size < cnt)
+-- On Fri, 15 May 2020, P J P wrote --+
| From: Prasad J Pandit
|
| A guest user may set channel frame count via es1370_write()
| such that, in es1370_transfer_audio(), total frame count
| 'size' is lesser than the number of frames that are processed
| 'cnt'.
|
| in
From: Prasad J Pandit
Hello,
* This patch series fixes an OOB access issue while performing block
write commands in SD card emulator.
* Second patch disables the sdhci-pci device build by default.
Thank you.
--
Prasad J Pandit (2):
sd: check bit number before setting card_status flag
sd:
From: Prasad J Pandit
SD card emulator sets 'sd->card_status' while performing block
write commands. While doing so, it tests the corresponding bit
derived from 's->data_start' address. This may lead to OOB access.
Add check to avoid it.
Reported-by: Alex
Signed-off-by: Prasad J Pandit
---
hw
701 - 800 of 917 matches
Mail list logo
