From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Alexander Bulekov <alxndr@bu.edu>, qemu-devel@nongnu.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: Abort in mch_update_pciexbar
Date: Mon, 11 May 2020 08:19:51 +0200 [thread overview]
Message-ID: <c6b66f8a-40e4-8ad5-afb4-09bddbcac529@redhat.com> (raw)
In-Reply-To: <20200511045912.keffhizkobgwqcag@mozz.bu.edu>
On 5/11/20 6:59 AM, Alexander Bulekov wrote:
> Hello,
> While fuzzing, I found an input that triggers an assertion failure in
> mch_update_pciexbar:
>
> #6 0x7f38d387c55a in abort /build/glibc-GwnBeO/glibc-2.30/stdlib/abort.c:79:7
> #7 0x55c27e94ffd0 in mch_update_pciexbar hw/pci-host/q35.c:331:9
> #8 0x55c27e94db38 in mch_write_config hw/pci-host/q35.c:487:9
> #9 0x55c27e9e3f4c in pci_host_config_write_common hw/pci/pci_host.c:81:5
> #10 0x55c27e9e5307 in pci_data_write hw/pci/pci_host.c:118:5
> #11 0x55c27e9e6601 in pci_host_data_write hw/pci/pci_host.c:165:9
> #12 0x55c27ca3b17b in memory_region_write_accessor memory.c:496:5
> #13 0x55c27ca3a5e4 in access_with_adjusted_size memory.c:557:18
> #14 0x55c27ca38177 in memory_region_dispatch_write memory.c:1488:16
> #15 0x55c27c721325 in flatview_write_continue exec.c:3174:23
> #16 0x55c27c70994d in flatview_write exec.c:3214:14
> #17 0x55c27c709462 in address_space_write exec.c:3305:18
These lines don't match QEMU v5.0.0.
>
> I can reproduce it in a qemu 5.0 build using:
> cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -display none -nodefaults -nographic -qtest stdio
> outl 0xcf8 0xf2000060
> outl 0xcfc 0x8400056e
The guest shouldn't ask for a reserved bar length (grep for
MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD). I suppose we should simply report
it as GUEST_ERROR and ignore it.
> EOF
>
> I also uploaded the above trace, in case the formatting is broken:
>
> curl https://paste.debian.net/plain/1146095 | qemu-system-i386 -M pc-q35-5.0 -display none -nodefaults -nographic -qtest stdio
>
> Please let me know if I can provide any further info.
It would help the community if you fill your bug reports with Launchpad,
so they don't get lost in the high email flow, and we can track/update
them. See for example:
https://bugs.launchpad.net/qemu/+bug/1835865 and
https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg06082.html
which refers it.
next prev parent reply other threads:[~2020-05-11 6:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 4:59 Abort in mch_update_pciexbar Alexander Bulekov
2020-05-11 6:19 ` Philippe Mathieu-Daudé [this message]
2020-05-11 7:10 ` Philippe Mathieu-Daudé
2020-05-11 7:39 ` Michael S. Tsirkin
2020-05-11 7:42 ` Philippe Mathieu-Daudé
2020-05-11 15:31 ` Alexander Bulekov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c6b66f8a-40e4-8ad5-afb4-09bddbcac529@redhat.com \
--to=philmd@redhat.com \
--cc=alxndr@bu.edu \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.