From: Helge Deller <deller@gmx.de>
To: Alexander Bulekov <alxndr@bu.edu>
Cc: "Richard Henderson" <rth@twiddle.net>,
qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH v3 7/8] hw/display/artist: Refactor artist_rop8() to avoid buffer over-run
Date: Sun, 9 Aug 2020 21:38:54 +0200 [thread overview]
Message-ID: <1d16f1cd-a57e-d56c-2e4f-09f594cc86b7@gmx.de> (raw)
In-Reply-To: <20200809171714.3qp72ubampclo4f2@mozz.bu.edu>
On 09.08.20 19:17, Alexander Bulekov wrote:
> On 200809 0717, Helge Deller wrote:
>> Hello Alexander,
>>
>> On 06.08.20 17:46, Alexander Bulekov wrote:
>>> On 200805 2244, Helge Deller wrote:
>>>> * Alexander Bulekov <alxndr@bu.edu>:
>>>>> On 200804 2320, Helge Deller wrote:
>>>>>> * Alexander Bulekov <alxndr@bu.edu>:
>>>>>>> I applied this series and it fixes most of the problems I saw before.
>>>>>>> I still see a few crashes - I made issues for them on launchpad:
>>>>>>> https://bugs.launchpad.net/qemu/+bug/1890310
>>>>>>> https://bugs.launchpad.net/qemu/+bug/1890311
>>>>>>> https://bugs.launchpad.net/qemu/+bug/1890312
>>>>> Hi Helge, I can still reproduce this one ^^^
>>>>> I'll fuzz it some more, but so far I am not finding anything else.
>>>>
>>>> I've now updated the patch which does address all issues you found
>>>> so far. It's attached below.
>>>>
>>> I pulled from your repo, but I can still reproduce LP1890312
>>> (I build with --enable-sanitizers). Maybe I am missing something? With
>>> this cleared up, I'm happy to leave an Acked-by for the artist patches
>>> in this series.
>>>
>>> git show --summary
>>> commit 1657a7a95adc15552138c2b4d310a06128093892 (HEAD, hppa/target-hppa, target-hppa)
>>> Author: Helge Deller <deller@gmx.de>
>>> Date: Tue Aug 4 15:35:38 2020 +0200
>>
>> The current tree at
>> https://github.com/hdeller/qemu-hppa/commits/target-hppa
>> does survive all your tests and in addition fixes an artist bug which
>> made the dtwm window manager rendering wrong on HP-UX.
>> Please completely revert your tree before pulling again.
>> I'll send out a complete patch series shortly.
>>
>
> Hi Helge,
> This still causes a segfault for me:
>
> cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \
> -qtest stdio -accel qtest
> writew 0xf8118001 0x105a
> readq 0xf900f8ff
> EOF
It's strange, I don't know why, but I can't reproduce it:
[deller@ls3530 qemu-helge-system]$ cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none -qtest stdio -accel qtest
writew 0xf8118001 0x105a
readq 0xf900f8ff
EOF
[I 1596999589.838131] OPENED
[R +0.006113] writew 0xf8118001 0x105a
OK
[S +0.006128] OK
[R +0.006137] readq 0xf900f8ff
OK 0x0000000000000000
[S +0.006141] OK 0x0000000000000000
[I +0.006163] CLOSED
Nevertheless, you are correct that there is a bounds check missing!
> I think the problem is that there is a bounds check missing on the
> artist_vram_read with s->cmap_bm_access path. The bounds check is
> present for artist_vram_write, so I just copied it over, and that fixed
> the issue (applied on top of the current qemu-hppa/target-hppa):
I'll apply it with minor modifications...
>
> diff --git a/hw/display/artist.c b/hw/display/artist.c
> index 720db179ab..678023bb3a 100644
> --- a/hw/display/artist.c
> +++ b/hw/display/artist.c
> @@ -1216,8 +1216,10 @@ static uint64_t artist_vram_read(void *opaque, hwaddr addr, unsigned size)
>
> if (s->cmap_bm_access) {
> buf = &s->vram_buffer[ARTIST_BUFFER_CMAP];
> - val = *(uint32_t *)(buf->data + addr);
> - trace_artist_vram_read(size, addr, 0, 0, val);
> + if (addr + 3 < buf->size) {
We need to check addr < buf->size too, otherwise with addr = 0xffffffff would succeed too:
if (addr < buf->size && addr + 3 < buf->size) {
> + val = *(uint32_t *)(buf->data + addr);
> + trace_artist_vram_read(size, addr, 0, 0, val);
> + }
> return 0;
This seems wrong... should be "return val;", otherwise the whole function
doesn't make sense.
Thank you!
Helge
next prev parent reply other threads:[~2020-08-09 19:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-04 14:00 [PATCH v3 0/8] target-hppa fixes v3 Helge Deller
2020-08-04 14:00 ` [PATCH v3 1/8] hw/hppa: Sync hppa_hardware.h file with SeaBIOS sources Helge Deller
2020-08-04 14:00 ` [PATCH v3 2/8] seabios-hppa: Update to SeaBIOS hppa version 1 Helge Deller
2020-08-04 14:00 ` [PATCH v3 3/8] hw/hppa: Implement proper SeaBIOS version check Helge Deller
2020-08-04 14:00 ` [PATCH v3 4/8] hw/display/artist.c: fix out of bounds check Helge Deller
2020-08-04 16:40 ` Alexander Bulekov
2020-08-04 14:00 ` [PATCH v3 5/8] hw/hppa/lasi: Don't abort on invalid IMR value Helge Deller
2020-08-04 14:00 ` [PATCH v3 6/8] hw/display/artist: Check offset in draw_line to avoid buffer over-run Helge Deller
2020-08-04 14:00 ` [PATCH v3 7/8] hw/display/artist: Refactor artist_rop8() " Helge Deller
2020-08-04 16:39 ` Alexander Bulekov
2020-08-04 21:20 ` Helge Deller
2020-08-04 22:01 ` Alexander Bulekov
2020-08-05 4:33 ` Alexander Bulekov
2020-08-05 20:44 ` Helge Deller
2020-08-06 15:46 ` Alexander Bulekov
2020-08-09 5:17 ` Helge Deller
2020-08-09 17:17 ` Alexander Bulekov
2020-08-09 19:38 ` Helge Deller [this message]
2020-08-09 19:51 ` Helge Deller
2020-08-09 23:52 ` [PATCH v3 7/8] hw/display/artist: Refactor artist_rop8() to avoid buffer over-runy Alexander Bulekov
2020-08-04 14:00 ` [PATCH v3 8/8] hw/display/artist: Prevent out of VRAM buffer accesses Helge Deller
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=1d16f1cd-a57e-d56c-2e4f-09f594cc86b7@gmx.de \
--to=deller@gmx.de \
--cc=alxndr@bu.edu \
--cc=f4bug@amsat.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).