From: Vincent Fazio
Previously, guest_loaddr was not taken into account when returning an
address from pgb_find_hole when /proc/self/maps was unavailable which
caused an improper guest_base address to be calculated.
This could cause a SIGSEGV later in load_elf_image -> target_mmap for
ET_EXEC ty
From: Vincent Fazio
Previously, if the build host's libc did not define MAP_FIXED_NOREPLACE
or if the running kernel didn't support that flag, it was possible for
pgd_find_hole_fallback to munmap an incorrect address which could lead to
SIGSEGV if the range happened to overlap with the mapped add
From: Vincent Fazio
Previously, pgd_find_hole_fallback assumed that if the build host's libc
had MAP_FIXED_NOREPLACE defined that the address returned by mmap would
match the requested address. This is not a safe assumption for Linux
kernels prior to 4.17
Now, we always compare mmap's resultant
*** 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
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:
* Gaoning
Public bug reported:
# System Details
AMD Ryzen 7 3700U
Ubuntu 20.04 Focal Focus
# Dockerfile
FROM arm32v7/debian:bullseye
RUN apt-get update && apt-get install -y mesa-utils
ENTRYPOINT glxgears
# Instructions For Reproduction
1. Install Docker
2. Build Docker Image: docker build --tag mesa-a
Public bug reported:
Hello,
I found an assertion failure in hw/net/vmxnet3.c:1793
This was found in latest version 5.2.0.
my reproduced is as follows:
cat << EOF | ./qemu-system-x86_64 \
-device vmxnet3 \
-display none -nodefaults -qtest stdio
outl 0xcf8 0x80001014
outl 0xcfc 0xf0001000
outl
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805697
Title:
egl-headles
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1804961
Title:
qemu-system
Hi John,
Thank you, this is indeed strange. Do you use homebrew? Could you try
the homebrew version and see how that goes?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913505
Title:
Windows XP s
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 -qtest stdio \
-machine raspi3b,accel=qtest -m 1G
write 0x3f30002c 0x1 0x25
write 0x3f34 0x1 0x01
write 0x3f36 0x1 0xc0
write 0x3f3c 0x1 0x22
write 0x3f3e 0x1 0x20
write 0x3f3f 0x1 0x0
write 0x3f30 0x1 0x4
** Summary changed:
- arm-virt: Null-ptr dereference through virtio_write_config
+ aarc64-virt: Null-ptr dereference through virtio_write_config
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913915
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
writel 0x8000f00 0x5affaf
write 0x8000eff 0x1 0x0
EOF
Stacktrace:
../hw/intc/arm_gic.c:1419:17: runtime error: index 3068 out of bounds for type
'gic_irq_state [1020]'
SUMMARY: UndefinedB
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
writel 0x8000f00 0xff4affb0
writel 0x8000f00 0xf2f8017f
writeq 0x801000e 0x5a5a5a6c8ff7004b
writeq 0x8010010 0x5a5a5a5a73ba2f00
writel 0x800 0x3bf5a03
writel 0x800 0x3bf5a03
writeq
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
writel 0x8000f00 0x81818191
write 0x4010008004 0x1 0x06
EOF
Stacktrace:
../hw/intc/arm_gic.c:1498:13: runtime error: index 401 out of bounds for type
'uint8_t [16][8]'
SUMMARY: UndefinedB
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
write 0x800 0x1 0x02
write 0x801 0x1 0x03
write 0x8010004 0x1 0x10
write 0x8000f2f 0x1 0x0
writel 0x8000f00 0x2065559
write 0x8000d56 0x1 0x0
readl 0x801000b
EOF
Stacktrace:
SUMMAR
Is this the same as https://bugs.launchpad.net/qemu/+bug/1890152 ?
--
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:
Public bug reported:
QEMU development version, git commit
74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in
5.2.0 generally.
Certain 16-bit windows programs crash WINE under QEMU linux-user with:
0084:err:seh:segv_handler Got unexpected trap -1
wine: Unhandled illegal instruc
Hi all,
In light of attempts to get Linux bootstrapped on the new M1 macs I've
been working on supporting them in QEMU as a new machine type, I think
this has benefits for testing and potentially there is desire for an
M1 Mac running QEMU to natively support emulating an M1 Mac and
potentially boo
On 1/30/21 12:53 AM, Claudio Fontana wrote:
> To summarize:
>
> 1) accel->cpu_realizefn extends the current cpu target-specific realize
> functions with accelerator-specific code,
>which currently does not make use of errp at all (thus, the temptation to
> remove errp from the interface unti
On Sat, 30 Jan 2021 at 18:36, Philippe Mathieu-Daudé wrote:
>
> Hi Peter,
>
> On 1/30/21 4:37 PM, Peter Maydell wrote:
> > On Sat, 30 Jan 2021 at 01:52, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> KVM requires a cpu based on (at least) the ARMv7 architecture.
> >
> > These days it requires ARMv8
On Jan 29 22:23, Aaron Lindsay wrote:
> 1. Is this considered a bug or a "feature"?
> 2.a. If a bug, is there a good way to detect this from inside the
>tcg/plugin infrastructure and avoid calling the callback for the
>faulting execution of the instruction?
> 2.b. If a "feature", is
When the frontend device has no space for a read the fd is removed
from polling to allow time for the guest to read and clear the buffer.
Without the call to qemu_chr_fe_accept_input(), the poll will not be
broken out of when the guest has cleared the buffer causing significant
IO delays that get w
Hi Peter,
On 1/30/21 4:37 PM, Peter Maydell wrote:
> On Sat, 30 Jan 2021 at 01:52, Philippe Mathieu-Daudé wrote:
>>
>> KVM requires a cpu based on (at least) the ARMv7 architecture.
>
> These days it requires ARMv8, because we dropped 32-bit host
> support, and all 64-bit host CPUs are v8.
Oh,
I was working on preparing this test case for the virt machine (I've been
using a test machine based around the exynos UART).
While looking at the uart code for the virt to find which serial peripheral
it uses (and the register layout), I noticed that the pl011
uart code calls qemu_chr_fe_accept_i
bsd-user: Add new mainatiners
The FreeBSD project has a number of enhancements to bsd-user. Add myself
as maintainer and Kyle Evans as a reviewer. Also add our github repo.
Signed-off-by: Warner Losh
---
MAINTAINERS | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/MAINTAI
>
> > I don't think this works well enough: if the source isn't removed, but
> fd_can_read() returns 0, there is a potential busy loop on the next
> > fd_read().
>
This shouldn't happen. The sources all get set to non-blocking mode, the
only
blocking code is the poll itself. If fd_can_read() retu
On Sat, 30 Jan 2021 at 01:52, Philippe Mathieu-Daudé wrote:
>
> KVM requires a cpu based on (at least) the ARMv7 architecture.
These days it requires ARMv8, because we dropped 32-bit host
support, and all 64-bit host CPUs are v8.
thanks
-- PMM
I already used this github URL for PRs before and will continue to use it in
foreseeable future.
Signed-off-by: Christian Schoenebeck
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index bcd88668bc..e8f49aeebd 100644
--- a/MAINTAINERS
+++ b/MAINTAIN
On 1/30/21 2:52 AM, Philippe Mathieu-Daudé wrote:
> KVM requires a cpu based on (at least) the ARMv7 architecture.
>
> Only enable the following ARMv4 CPUs when TCG is available:
>
> - StrongARM (SA1100/1110)
> - OMAP1510 (TI925T)
>
> The following machines are no more built when TCG is disa
+-- 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: C
** 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 QEMU
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:/
On Sat, 30 Jan 2021 at 10:11, Marc-André Lureau
wrote:
> That's weird,
> https://patchew.org/QEMU/20210129111814.566629-1-pbonz...@redhat.com/20210129111814.566629-24-pbonz...@redhat.com/
>
> -Subproject commit 8f43a99191afb47ca3f3c6972f6306209f367ece
> +Subproject commit 5dce846e3ee82d93462bc637
On 1/29/21 1:13 AM, Richard Henderson wrote:
> On 1/28/21 6:29 AM, Philippe Mathieu-Daudé wrote:
>> On 1/28/21 5:08 PM, Alex Bennée wrote:
>>>
>>> Claudio Fontana writes:
>>>
On 1/28/21 2:03 PM, Philippe Mathieu-Daudé wrote:
> On 1/28/21 10:28 AM, Claudio Fontana wrote:
>>>
>> +
Hi Philippe,
On Fri, Jan 29, 2021 at 10:11 PM Philippe Mathieu-Daudé wrote:
>
> Hi Bin,
>
> On 1/29/21 9:51 AM, Bin Meng wrote:
> > From: Bin Meng
> >
> > Unlike SD mode, when SD card is working in SPI mode, the argument
> > of CMD13 is stuff bits. Hence we should bypass the RCA check.
>
> Is th
Hi
On Fri, Jan 29, 2021 at 11:56 PM Paolo Bonzini wrote:
>
> On 29/01/21 20:49, Peter Maydell wrote:
> > On Fri, 29 Jan 2021 at 11:33, Paolo Bonzini wrote:
> >>
> >> The following changes since commit
> >> 0bcd12fb1513bad44f05f2d3a8eef2a99b3077b6:
> >>
> >>Merge remote-tracking branch 'remo
On Fri, Jan 29, 2021 at 11:57 PM Iris Johnson wrote:
>
> Currently, the chardev backend code will prepare for IO polling to occur
> by potentially adding or removing a watch of the backing channel for the
> chardev. The chardev poll is added if the fd_can_read() function reports
> more than 0 byte
On 1/29/21 8:36 PM, Eduardo Habkost wrote:
> On Fri, Jan 29, 2021 at 09:19:00AM -1000, Richard Henderson wrote:
>> On 1/28/21 11:00 PM, Claudio Fontana wrote:
>>> Do you think I should redo the series anyway? I would have started this way
>>> in the first place, but I tried not to redo Eduardo's wo
On 1/29/21 9:15 PM, Stefan Weil wrote:
> If someone decides to use TCG_TARGET_HAS_div2_i64 instead of
> TCG_TARGET_HAS_div_i64 with TCI, that lines (in addition to the implementation
> of the opcodes) would be needed again.
How can you know if those lines are even correct, when there is no
infrast
40 matches
Mail list logo
