+-- On Mon, 10 Oct 2016, no-re...@ec2-52-6-146-230.compute-1.amazonaws.com
wrote --+
| Your series failed automatic build test. Please find the testing commands and
| their output below. If you have docker installed, you can probably reproduce
it
| locally.
I tried to build it locally(without
From: Prasad J Pandit
16550A UART device uses an oscillator to generate frequencies
(baud base), which decide communication speed. This speed could
be changed by dividing it by a divider. If the divider is
greater than the baud base, speed is set to zero, leading to a
divide by zero error. Add ch
+-- On Tue, 11 Oct 2016, no-re...@ec2-52-6-146-230.compute-1.amazonaws.com
wrote --+
| Your series seems to have some coding style problems.
| === OUTPUT BEGIN ===
| Checking PATCH 1/1: char: serial: check divider value against baud base...
| ERROR: braces {} are necessary for all arms of this sta
From: Prasad J Pandit
Rocker network switch emulator has test registers to help debug
DMA operations. While testing host DMA access, a buffer address
is written to register 'TEST_DMA_ADDR' and its size is written to
register 'TEST_DMA_SIZE'. When performing TEST_DMA_CTRL_INVERT
test, if DMA buffe
From: Prasad J Pandit
The JAZZ RC4030 chipset emulator has a periodic timer and
associated interval reload register. The reload value is used
as divider when computing timer's next tick value. If reload
value is large, it could lead to divide by zero error. Limit
the interval reload value to avoi
+-- On Wed, 12 Oct 2016, Peter Maydell wrote --+
| > -while (gtb->compare < update.new) {
| > +if (gtb->compare < update.new) {
| >
| > +inc = update.new - gtb->compare - 1;
|
| Can you explain why the '- 1' here ?
I think I did that because while was
From: Prasad J Pandit
ARM A9MP processor has a peripheral timer with an auto-increment
register, which holds an increment step value. A user could set
this value to zero. When auto-increment control bit is enabled,
it leads to an infinite loop in 'a9_gtimer_update' while
updating comparator value
+-- On Thu, 13 Oct 2016, Peter Maydell wrote --+
| I suggest you try putting in some sample values for the
| various variables to confirm that your new code produces the
| same answers that the old code did.
Yep, sent a revised patch v5. Thank you.
--
Prasad J Pandit / Red Hat Product Security Tea
From: Prasad J Pandit
ARM A9MP processor has a peripheral timer with an auto-increment
register, which holds an increment step value. A user could set
this value to zero. When auto-increment control bit is enabled,
it leads to an infinite loop in 'a9_gtimer_update' while
updating comparator value
+-- On Fri, 14 Oct 2016, P J P wrote --+
| +if (gtb->control & R_CONTROL_AUTO_INCREMENT && gtb->inc) {
| +inc = update.new - gtb->compare;
| +inc = MAX(QEMU_ALIGN_DOWN(inc, gtb->inc), gtb->inc);
| +
+-- On Mon, 17 Oct 2016, Peter Maydell wrote --+
| > +inc = QEMU_ALIGN_DOWN(inc, gtb->inc);
|
| Isn't this pair of lines equivalent to
| uint64_t inc = QEMU_ALIGN_UP(update.new - gtb->compare, gtb->inc);
| ?
Yes, sent v7. Thank you.
--
Prasad J Pandit / Red Hat Product Secur
===
From 632498fa33248bb990b08f246c98f3f318aa631c Mon Sep 17 00:00:00 2001
From: Prasad J Pandit
Date: Mon, 17 Oct 2016 23:56:01 +0530
Subject: [PATCH v7] timer: a9gtimer: remove loop to auto-increment comparator
ARM A9MP processor has a peripheral timer with an auto-increment
register, which
From: Prasad J Pandit
ARM A9MP processor has a peripheral timer with an auto-increment
register, which holds an increment step value. A user could set
this value to zero. When auto-increment control bit is enabled,
it leads to an infinite loop in 'a9_gtimer_update' while
updating comparator value
From: Prasad J Pandit
In Cirrus CLGD 54xx VGA Emulator, if cirrus graphics mode is VGA,
'cirrus_get_bpp' returns zero(0), which could lead to a divide
by zero error in while copying pixel data. The same could occur
via blit pitch values. Add check to avoid it.
Reported-by: Huawei PSIRT
Signed-o
From: Prasad J Pandit
The Cadence UART device emulator calculates speed by dividing the
baud rate by a divider. If this divider was to be zero or if baud
rate was to be lesser than the divider, it could lead to a divide
by zero error. Add check to avoid it.
Reported-by: Huawei PSIRT
Signed-off-
From: Prasad J Pandit
The STM32F2XX Timer emulator uses a 16 bit prescaler value to
limit the timer clock rate. It does that by dividing the timer
frequency. If the prescaler 's->tim_psc' was set to be UINT_MAX,
it'd lead to divide by zero error. Limit prescaler value to 16
bits to avoid it.
Rep
+-- On Tue, 18 Oct 2016, Peter Maydell wrote --+
| > +if (!s->r[R_BRGR] || !(s->r[R_BDIV] + 1)
| > +|| baud_rate < (s->r[R_BRGR] * (s->r[R_BDIV] + 1))) {
| > +return;
| > +}
| > ssp.speed = baud_rate / (s->r[R_BRGR] * (s->r[R_BDIV] + 1));
| > packet_size = 1;
|
|
Hello Jason,
+-- On Thu, 11 Aug 2016, Dmitry Fleytman wrote --+
| Reviewed-by: Dmitry Fleytman
|
| > @@ -531,6 +531,7 @@ static void vmxnet3_complete_packet(VMXNET3State *s,
int qidx, uint32_t tx_ridx)
| >
| > VMXNET3_RING_DUMP(VMW_RIPRN, "TXC", qidx,
&s->txq_descr[qidx].comp_ring);
| >
Hello Alistair,
+-- On Wed, 19 Oct 2016, Alistair Francis wrote --+
| Generally these types of IP just say 'undefined' in invalid situations
| like this. If that is the case we shouldn't return but just set some
| default value and allow the other functions in the setup to continue
| on.
Coul
+-- On Wed, 19 Oct 2016, Alistair Francis wrote --+
| I don't think the Cadence datasheets are public. If you can't find it
| from a simple Google search I don't think you have access.
I see, okay.
I think it'll greatly help if device emulator writers include a link to its
specification/datash
From: Prasad J Pandit
Intel HDA emulator uses stream of buffers during DMA data
transfers. Each entry has buffer length and buffer pointer
position, which are used to derive bytes to 'copy'. If this
length and buffer pointer were to be same, 'copy' could be
set to zero(0), leading to an infinite
Hello Gerd,
+-- On Thu, 20 Oct 2016, Stefan Hajnoczi wrote --+
| A RHEL 7.2 guest sometimes hangs when I play back a wav file on the
| Intel HDA emulated sound card using the QEMU ALSA audio driver.
|
| intel_hda_xfer() transfers samples between the emulated card and the
| QEMU audio subsystem.
+-- On Thu, 20 Oct 2016, Edgar E. Iglesias wrote --+
| The UART is described in the Zynq TRMs, I think you can just
| google for zynq TRM and a reference to UG585 and UG1085 will come up.
Unlikely for a novice to think 'zynq TRM' as search term for cadence UART. I
went with Xilinx Cadence UART
From: Prasad J Pandit
RTL8139 ethernet controller in C+ mode supports multiple
descriptor rings, each with maximum of 64 descriptors. While
processing transmit descriptor ring in 'rtl8139_cplus_transmit',
it does not limit the descriptor count and runs forever. Add
check to avoid it.
Reported-by
From: Prasad J Pandit
NVME Express Controller has two queues, submission & completion
queue. When creating a new queue object, 'nvme_create_sq' and
'nvme_create_cq' routines incorrectly check the queue id field.
It could lead to an OOB access issue. Correct the queue id check
to avoid it.
Report
+-- On Sat, 22 Oct 2016, Peter Maydell wrote --+
| Secondly, it's almost the same as this cleanup
| patch from Thomas Huth that's already in qemu-trivial:
| http://patchwork.ozlabs.org/patch/681349/
|
| except that your version is removing the !
| negations from the return value.
|
| Can you expl
+-- On Tue, 18 Oct 2016, P J P wrote --+
| Use QEMU_ALIGN_UP instead of QEMU_ALIGN_DOWN
| -> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03788.html
|
| diff --git a/hw/timer/a9gtimer.c b/hw/timer/a9gtimer.c
| index 772f85f..ce1dc63 100644
| --- a/hw/timer/a9gtimer.c
| +++ b
Hello Jason,
+-- On Mon, 24 Oct 2016, Jason Wang wrote --+
| > RTL8139 ethernet controller in C+ mode supports multiple
| > descriptor rings, each with maximum of 64 descriptors. While
| > processing transmit descriptor ring in 'rtl8139_cplus_transmit',
| > it does not limit the descriptor count
From: Prasad J Pandit
The Cadence UART device emulator calculates speed by dividing the
baud rate by a 'baud rate generator' & 'baud rate divider' value.
The device specification defines these register values to be
non-zero and within certain limits. Add checks for these limits
to avoid errors li
+-- On Mon, 24 Oct 2016, Alistair Francis wrote --+
| > |
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
|
| Did the TRM have enough detail for you to figure out how the hardware behaves?
Yes, it defines range for 'Baud rate generator' and 'Baud rate divider'
From: Prasad J Pandit
virtio back end uses set of buffers to facilitate I/O operations.
An infinite loop unfolds in virtqueue_pop() if a buffer was
of zero size. Add check to avoid it.
Reported-by: Li Qiang
Signed-off-by: Prasad J Pandit
---
hw/virtio/virtio.c | 5 +
1 file changed, 5 ins
From: Prasad J Pandit
VMware VMXNET* NIC emulator supports packet fragmentation.
While fragmenting a packet, it checks for more fragments based
on packet length and current fragment length. It is susceptible
to an infinite loop, if the current fragment length is zero.
Add check to avoid it.
Repo
From: Prasad J Pandit
Network transport abstraction layer supports packet fragmentation.
While fragmenting a packet, it checks for more fragments from
packet length and current fragment length. It is susceptible
to an infinite loop, if the current fragment length is zero.
Add check to avoid it.
Hello Jason,
+-- On Thu, 4 Aug 2016, Jason Wang wrote --+
| The patch doesn't apply cleanly on HEAD, we now move this logic to
| hw/net/net_tx_pkt.c. Please resend on top of HEAD and cc Dmitry Fleytman
| .
I see, that explains why it did not show-up in search. I've sent a revised
patch v2.
From: Prasad J Pandit
While reading magic sequence(MFI_SEQ) in megasas_mmio_write,
an off-by-one error could occur as 's->adp_reset' index is not
reset after reading the last sequence.
Reported-by: YY Z
Signed-off-by: Prasad J Pandit
---
hw/scsi/megasas.c | 10 +-
1 file changed, 5 in
Hello Jason,
+-- On Mon, 26 Sep 2016, P J P wrote --+
| +-- On Fri, 23 Sep 2016, Jason Wang wrote --+
| | Actually the patch does not apply cleanly. Please fix and repost.
|
| The 'net: imx:...' patch is for v2.6 series. I missed to indicate that in
| Patch v2. Could you please t
From: Prasad J Pandit
When setting dma channel 'data_type', if (value & 3) == 3,
the set 'data_type' is said to be bad. This also leads to an
OOB access in 'omap_dma_transfer_generic', while doing
cpu_physical_memory_r/w operations. Add check to avoid it.
Reported-by: Jiang Xin
Signed-off-by: P
From: Prasad J Pandit
While doing multi block SDMA transfer in routine
'sdhci_sdma_transfer_multi_blocks', the 's->fifo_buffer' starting
index 'begin' and data length 's->data_count' could end up to be same.
This could lead to an OOB access issue. Correct transfer data length
to avoid it.
Report
From: Prasad J Pandit
In SDHCI device emulation the transfer mode register value
is used during multi block transfer to check if block count
register is enabled and should be updated. Transfer mode
register could be set such that, block count register would
not be updated, thus leading to an infi
From: Prasad J Pandit
In SDHCI device emulation the 'Block count enable' bit
of the Transfer Mode register is only relevant in multi block
transfers. We need not check it in single block transfers.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 6 +-
1 file changed, 1 insertion(+), 5 d
From: Prasad J Pandit
Hello,
In SDHCI emulation, the 'Block Count Enable' bit of the Transfer Mode
register is used to control 's->blkcnt' value. One, this bit is not
relevant in single block transfers. Second, Transfer Mode register
value could be set such that 's->blkcnt' would not see an upda
+-- On Thu, 26 Jan 2017, P J P wrote --+
| +-- On Mon, 26 Sep 2016, P J P wrote --+
| | +-- On Fri, 23 Sep 2016, Jason Wang wrote --+
| | | Actually the patch does not apply cleanly. Please fix and repost.
| |
| | The 'net: imx:...' patch is for v2.6 series. I missed to indicate th
From: Prasad J Pandit
i.MX Fast Ethernet Controller uses buffer descriptors to manage
data flow to/fro receive & transmit queues. While transmitting
packets, it could continue to read buffer descriptors if a buffer
descriptor has length of zero and has crafted values in bd.flags.
Set an upper lim
Hello Jason,
+-- On Thu, 26 Jan 2017, P J P wrote --+
| This patch still isn't merged upstream it seems. Could you please check?
-> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00380.html
I have sent a revised patch v3. Please consider this one.
Thank you.
--
Prasad
From: Prasad J Pandit
CCID device emulator uses Application Protocol Data Units(APDU)
to exchange command and responses to and from the host.
The length in these units couldn't be greater than 65536. Add
check to ensure the same. It'd also avoid potential integer
overflow in emulated_apdu_from_gu
+-- On Tue, 31 Jan 2017, P J P wrote --+
| In SDHCI emulation, the 'Block Count Enable' bit of the Transfer Mode
| register is used to control 's->blkcnt' value. One, this bit is not
| relevant in single block transfers. Second, Transfer Mode register
| value could be s
+-- On Tue, 7 Feb 2017, Peter Maydell wrote --+
| On 31 January 2017 at 12:24, P J P wrote:
| > In SDHCI emulation, the 'Block Count Enable' bit of the Transfer Mode
| > register is used to control 's->blkcnt' value. One, this bit is not
| > relevant in single b
+-- On Tue, 7 Feb 2017, Alistair Francis wrote --+
| > ===
| > diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
| > index d921423..7f3d547 100644
| > --- a/hw/sd/sdhci.c
| > +++ b/hw/sd/sdhci.c
| > @@ -1019,7 +1019,11 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t
val,
| > unsigned size)
| >
Hello Alistair,
+-- On Tue, 7 Feb 2017, Alistair Francis wrote --+
| As it doesn't look like we have ever supported an infinite transfer
| and we don't want infinite loops occurring I think we should add an
| unsupported print statement here saying that we don't support infinite
| transfers and
From: Prasad J Pandit
Hello,
In SDHCI protocol, the 'Block Count Enable' bit of the Transfer Mode
register is used to control 's->blkcnt' value. One, this bit is not
relevant in single block transfers. Second, Transfer Mode register
value could be set such that 's->blkcnt' would not see an updat
From: Prasad J Pandit
In SDHCI device emulation the transfer mode register value
is used during multi block transfer to check if block count
register is enabled and should be updated. Transfer mode
register could be set such that, block count register would
not be updated, thus leading to an infi
From: Prasad J Pandit
In sdhci_write invoke multi block transfer if it is enabled
in the transfer mode register 's->trnmod'.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index cf400c8..53
From: Prasad J Pandit
In the SDHCI protocol the 'Block count enable' bit
of the Transfer Mode register is relevant only in multi block
transfers. We need not check it in single block transfers.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 6 +-
1 file changed, 1 insertion(+), 5 delet
From: Prasad J Pandit
When processing completed commands, if SCSIRequest object
'cmd->req' was null, it could lead to null pointer dereference
in megasas_complete_command. Add check to avoid it.
Reported-by: Zhangyanyu
Signed-off-by: Prasad J Pandit
---
hw/scsi/megasas.c | 8 +---
1 file
Hello Paolo,
+-- On Wed, 10 May 2017, Paolo Bonzini wrote --+
| What version was this reported for? It should be fixed in v2.8.0 and
| newer by commit 9e55d58806 ("megasas: clean up and fix request
| completion/cancellation", 2016-11-28).
I checked the reproducer against current upstream git,
From: Prasad J Pandit
Hello,
In SDHCI protocol, the 'Block Count Enable' bit of the Transfer Mode
register is used to control 's->blkcnt' value. This bit is not relevant
in single block transfers. Also, Transfer Mode register value could be
set such that 's->blkcnt' would not see an update durin
From: Prasad J Pandit
In SDHCI protocol, the transfer mode register is defined
to be of 6 bits. Mask its value with '0x0037' so that an
invalid value couldn't be assigned.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Update: mask s->tr
From: Prasad J Pandit
In sdhci_write invoke multi block transfer if it is enabled
in the transfer mode register 's->trnmod'.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Update: test if (s->trnmod & SDHC_TRNS_MULTI) is true
-> h
From: Prasad J Pandit
In SDHCI protocol, the 'Block count enable' bit of the Transfer
Mode register is relevant only in multi block transfers. We need
not check it in single block transfers.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 6 +-
1 file changed, 1 insertion(+), 5 deletion
From: Prasad J Pandit
In the SDHCI protocol, the transfer mode register value
is used during multi block transfer to check if block count
register is enabled and should be updated. Transfer mode
register could be set such that, block count register would
not be updated, thus leading to an infinit
From: Prasad J Pandit
xHCI controller emulator loops through the transfer ring to
transfer control/data between host memory and device endpoints.
It continues to do so after processing 'Status Stage' TD which
is the last descriptor in control transfer. Add break to avoid
infinite loop.
Reported-
From: Prasad J Pandit
In SDHCI protocol, the transfer mode register is defined
to be of 6 bits. Mask its value with '0x0037' so that an
invalid value could not be assigned.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Update per: use
+-- On Mon, 13 Feb 2017, Alistair Francis wrote --+
| > -MASKED_WRITE(s->trnmod, mask, value);
| > +MASKED_WRITE(s->trnmod, mask, value & 0x0037);
|
| This looks good.
|
| Can you use a macro for the value so then it is explained and easier
| to change in the future?
Done, sent
+-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
| What has happened to the other patches that were in this patchset in v3 ?
v3 1/4
-> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02776.html
v3 3/4
-> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02775.html
These two a
Hello Peter,
+-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
| Please keep sending them as a single series, though. Otherwise I
| won't be able to easily apply them in the right order and track
| their current status.
Okay, got it. Ie. to re-send entire series even for change in one of the
Hello Petr,
+-- On Tue, 14 Feb 2017, Peter Maydell wrote --+
| Yes, exactly. (We document this in
|
http://wiki.qemu-project.org/Contribute/SubmitAPatch#Participating_in_Code_Review
| but of course that page is huge...)
Right, okay. I'll resend the patch set later today.
Thank you.
--
Pr
From: Prasad J Pandit
Hello,
In SDHCI protocol, the 'Block Count Enable' bit of the Transfer Mode
register is used to control 's->blkcnt' value. This bit is not relevant
in single block transfers. Also, Transfer Mode register value could be
set such that 's->blkcnt' would not see an update durin
From: Prasad J Pandit
In SDHCI protocol, the transfer mode register is defined
to be of 6 bits. Mask its value with '0x0037' so that an
invalid value could not be assigned.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Update per: use
From: Prasad J Pandit
In the SDHCI protocol, the transfer mode register value
is used during multi block transfer to check if block count
register is enabled and should be updated. Transfer mode
register could be set such that, block count register would
not be updated, thus leading to an infinit
From: Prasad J Pandit
In sdhci_write invoke multi block transfer if it is enabled
in the transfer mode register 's->trnmod'.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index f8220c0..8a
From: Prasad J Pandit
In SDHCI protocol, the 'Block count enable' bit of the Transfer
Mode register is relevant only in multi block transfers. We need
not check it in single block transfers.
Signed-off-by: Prasad J Pandit
---
hw/sd/sdhci.c | 6 +-
1 file changed, 1 insertion(+), 5 deletion
Hello Alistair,
+-- On Tue, 14 Feb 2017, Alistair Francis wrote --+
| On Tue, Feb 14, 2017 at 10:52 AM, P J P wrote:
| > From: Prasad J Pandit
| >
| > In the SDHCI protocol, the transfer mode register value
| > is used during multi block transfer to check if block count
| &
+-- On Fri, 17 Feb 2017, Peter Maydell wrote --+
| Alistair's point is that when you resend a patchset where some patches have
| got reviews/acks and those patches haven't changed significantly, you should
| include the Reviewed-by: or Acked-by: tags in the commit messages on the
| resent patche
From: Prasad J Pandit
Crypto routines 'qcrypto_cipher_get_block_len' and
'qcrypto_cipher_get_key_len' return non-zero cipher block and key
lengths from static arrays 'alg_block_len[]' and 'alg_key_len[]'
respectively. Returning 'zero(0)' value from either of them would
likely lead to an error con
From: Prasad J Pandit
Limit the number of arguments passed to execve(2) call from
a user program, as large number of them could lead to a bad
guest address error.
Reported-by: Jann Horn
Signed-off-by: Prasad J Pandit
---
linux-user/syscall.c | 7 +++
1 file changed, 7 insertions(+)
diff
+-- On Fri, 3 Mar 2017, Jann Horn wrote --+
| On Fri, Mar 3, 2017 at 4:55 PM, Peter Maydell
wrote:
| >> +if (argc > ARG_MAX || envc > ARG_MAX) {
| >> +fprintf(stderr,
| >> +"argc(%d), envc(%d) exceed %d\n", argc, envc,
ARG_MAX);
| >> +
From: Prasad J Pandit
Limit the number of arguments passed to execve(2) call from
a user program, as large number of them could lead to a bad
guest address error.
Reported-by: Jann Horn
Signed-off-by: Prasad J Pandit
---
linux-user/syscall.c | 6 ++
1 file changed, 6 insertions(+)
Update
From: Prasad J Pandit
Hello,
A user program could pass large number of 'argv','env' arguments to an
execve(2) call. It could lead to bad behaviour as the TARGET_NR_execve:
allocates stack memory(via alloca) for these arguments. alloca(3) is
better for allocations of upto one page(4KB) of stack m
From: Prasad J Pandit
Arguments passed to execve(2) call from user program could
be large, allocating stack memory for them via alloca(3) call
would lead to bad behaviour. Use 'g_malloc0' to allocate memory
for such arguments.
Signed-off-by: Prasad J Pandit
---
linux-user/syscall.c | 7 +--
Hello Eric,
+-- On Fri, 3 Mar 2017, Eric Blake wrote --+
| much smaller, or you should consider using the heap instead of the stack
| (alloca should never be used for more than about 4k). And there's still
| the possibility that even with your cap, that you are not handling E2BIG
| correctly.
+-- On Mon, 6 Mar 2017, Eric Blake wrote --+
| On 03/06/2017 01:17 AM, P J P wrote:
| > Arguments passed to execve(2) call from user program could
| > be large, allocating stack memory for them via alloca(3) call
| > would lead to bad behaviour. Use 'g_malloc0' to allocate
+-- On Mon, 6 Mar 2017, Eric Blake wrote --+
| If you impose any limit smaller than _SC_ARG_MAX, you are needlessly
| limiting things. Furthermore, _SC_ARG_MAX may not always be the same
| value, depending on how the kernel was compiled. So it's probably
| asiest to just let execve() impose its o
From: Prasad J Pandit
Arguments passed to execve(2) call from user program could
be large, allocating stack memory for them via alloca(3) call
would lead to bad behaviour. Use 'g_new0' to allocate memory
for such arguments.
Reported-by: Jann Horn
Signed-off-by: Prasad J Pandit
---
linux-user/
From: Li Qiang
Vmxnet3 device emulator does not check if the device is active,
before using it for write. It leads to a use after free issue,
if the vmxnet3_io_bar0_write routine is called after the device is
deactivated. Add check to avoid it.
Reported-by: Li Qiang
Signed-off-by: Prasad J Pand
From: Li Qiang
In Vmxnet3 device emulator while processing transmit(tx) queue,
when it reaches end of packet, it calls vmxnet3_complete_packet.
In that local 'txcq_descr' object is not initialised, which could
leak host memory bytes a guest.
Reported-by: Li Qiang
Signed-off-by: Prasad J Pandit
From: Li Qiang
When net transport abstraction layer initialises the pkt,
the maximum fragmentation count is not checked. This could
lead to an integer overflow causing a NULL pointer dereference.
Add check to avoid it.
Reported-by: Li Qiang
Signed-off-by: Prasad J Pandit
---
hw/net/net_tx_pkt
From: Prasad J Pandit
At various places in 9pfs back-end, it creates full path by
concatenating two path strings. It could lead to a path
traversal issue if one of the parameter was a relative path.
Add check to avoid it.
Reported-by: Felix Wilhelm
Signed-off-by: Prasad J Pandit
---
hw/9pfs/9
From: Li Qiang
When network transport abstraction layer initialises pkt, the maximum
fragmentation count is not checked. This could lead to an integer
overflow causing a NULL pointer dereference. Replace g_malloc() with
g_new() to catch the multiplication overflow.
Reported-by: Li Qiang
Signed-
Hello Peter, all
+-- On Mon, 22 Aug 2016, Peter Maydell wrote --+
| Opinions welcome on whether we need to hold 2.7 for this bug.
I'm going through the VirtFS details to figure out a best fix for this
issue. Nonetheless, IMO we need not hold 2.7 release for this bug.
Thank you.
--
Prasad J
From: Prasad J Pandit
When processing ATA_CACHE_FLUSH ide controller command,
BlockDriverState object could be null. Add check to avoid
null pointer dereference.
Reported-by: Kieron Shorrock
Signed-off-by: Prasad J Pandit
---
block/block-backend.c | 9 +++--
1 file changed, 7 insertions(+
From: Prasad J Pandit
When accessing guest's ram block during DMA operation, use
'qemu_ram_ptr_length' to get ram block pointer. It ensures
that DMA operation of given length is possible; And avoids
any OOB memory access situations.
Reported-by: Alex
Signed-off-by: Prasad J Pandit
---
exec.c
From: Prasad J Pandit
When cancelling pending DMA requests in ide_cancel_dma_sync,
the s->blk object could be null, leading to a null dereference.
Add check to avoid it.
Reported-by: Chensongnian
Signed-off-by: Prasad J Pandit
---
hw/ide/core.c | 6 --
1 file changed, 4 insertions(+), 2 d
From: Prasad J Pandit
While parsing dhcp options string in 'dhcp_decode', if an options'
length 'len' appeared towards the end of 'bp_vend' array, ensuing
read could lead to an OOB memory access issue. Add check to avoid it.
Reported-by: Reno Robert
Signed-off-by: Prasad J Pandit
---
slirp/bo
From: Prasad J Pandit
When cancelling pending DMA requests in ide_cancel_dma_sync,
the s->blk object could be null, leading to a null dereference.
Add check to avoid it.
blk_bs (blk=0x0) at block/block-backend.c:389
blk_drain (blk=0x0) at block/block-backend.c:1232
ide_cancel_dma_sync (s=0
Hello Kevin,
+-- On Mon, 17 Jul 2017, Kevin Wolf wrote --+
| I think Stefan didn't only mean a stack trace, but an actual instruction
| how to reproduce this. VM configuration, what actions to take, etc.
|
| In fact, I will add that we will probably want a qtest case as a
| regression test anyw
+-- On Tue, 27 Jun 2017, Eric Blake wrote --+
| > $ qemu-nbd -x foo -f raw -t null-co:// &
| > [1] 12726
| > $ qemu-io -c quit nbd://localhost/bar
| > can't open device nbd://localhost/bar: No export with name 'bar' available
| > [1] + 12726 broken pipe qemu-nbd -x foo -f raw -t null-co://
| >
|
Hello Samuel,
+-- On Wed, 23 Aug 2017, Samuel Thibault wrote --+
| The paste is not available any more. Is it really very large? It's usually
| really better to just send it by mail, so it's archived in the mailing list
| etc.
Yes, stack-trace was quite long.
===
==2704==ERROR: AddressSaniti
Hello Samuel,
+-- On Sat, 26 Aug 2017, Samuel Thibault wrote --+
| So Wjjzhang and PJP, can you confirm that this fixes your uses?
Yes, I confirm the patch fixes the use-after-free issue.
Thank you so much.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3
+-- On Fri, 25 Aug 2017, Gerd Hoffmann wrote --+
| > Do we have the actual number?
| Not yet, pjp still busy getting one, but will be filled for the final
| version of the patch.
CVE-2017-13672.
-> https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04684.html
CVE-2017-13673.
-> https://l
Hello Jan, Samuel
Wjjzhang(CC'd) has reported a use-after-free issue which seems to occur while
responding to a packet, after the socket has been closed by another thread.
===
==31922==ERROR: AddressSanitizer: heap-use-after-free on address 0x6141ff8c
at pc 0x56485de28ea0 bp 0x7f00f44fc
301 - 400 of 917 matches
Mail list logo
