From: Warisjeet Singh (sin99xx) <sinxx198@gmail.com>
To: qemu-devel@nongnu.org
Cc: marcandre.lureau@redhat.com
Subject: Re: [PATCH] vga: split text renderer geometry cache from graphics renderer
Date: Sun, 23 Aug 2026 12:41:01 -0400 [thread overview]
Message-ID: <vga-v2-reply-20260823.sinxx198@gmail.com> (raw)
In-Reply-To: <CAJ+F1CK7TVCTrPsRHtHj3VYqa1vKnFGck5mrGqFdPib=tH0CNw@mail.gmail.com>
Hi Marc-André,
On Sat, Aug 22, 2026, Marc-André Lureau wrote:
> No worries, but drop it from the commit message, or use '---'
> (three-dashes, see git-am(1)) section instead.
Done — v2 keeps notes under '---' only.
> Also add
> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4215
Added.
> But the patch doesn't fix the test you reported though.. Can you
> check? Compile qemu with ASAN.
You were right, and I found the exact reason. The split alone is
insufficient because the text predicate still can't observe the console
surface being replaced by the graphics renderer:
- G1 in my reproducer is a *legacy* (non-VBE) graphics mode, and
vga_get_bpp() returns 0 there — so s->last_depth stays 0 and the
"|| s->last_depth" term that normally forces a resize after a
graphics frame never fires.
- With v1, last_text_width/last_text_height still hold (80, 25) from
the first text frame, so the T2 predicate compares equal, the resize
is skipped, and the glyph loop paints 720x400 px into the 80x25 px
surface the graphics path left behind.
v2 keeps the split (units are now unambiguous) and adds the term that
actually catches the swap: the text path compares the pixel size it is
about to paint (width*cw x height*cheight) against the console
surface's real dimensions, and resizes on mismatch. Caches in either
unit can be stale wrt the surface; the surface cannot.
Verification (master @ eea8fe61b8 and v11.1.0, same qtest PoC as in
the report):
- unpatched: SIGSEGV in vga_draw_glyph9() during the T2 render.
- v2 patched: T2 forces the console resize, QEMU survives, subsequent
screendumps work.
- ASAN build with qemu_pixman_shareable_alloc()/free() routed to
g_malloc() as you suggested: unpatched, the PoC triggers
"heap-buffer-overflow WRITE of size 4" in vga_draw_glyph9()
(vga-helpers.h:80), 0 bytes after the 8000-byte surface region —
fired through the ordinary console refresh BH, no screendump needed.
With v2 applied the same run is clean (no ASAN report, all redraws
succeed).
v2 sent as a new thread: [PATCH v2] hw/display/vga: fix text-mode OOB
write after a graphics surface switch.
Regards,
Warisjeet
prev parent reply other threads:[~2026-08-23 16:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 19:27 [PATCH] vga: split text renderer geometry cache from graphics renderer sin99xx
2026-08-22 13:07 ` Marc-André Lureau
2026-08-23 16:41 ` Warisjeet Singh [this message]
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=vga-v2-reply-20260823.sinxx198@gmail.com \
--to=sinxx198@gmail.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.