ati: mask x y display parameter values

From: Prasad J Pandit <pjp@fedoraproject.org>

The source and destination x,y display parameters in ati_2d_blt()
may run off the vga limits if either of s->regs.[src|dst]_[xy] is
zero. Mask the register values to avoid potential crash.

Reported-by: Gaoning Pan <pgn@zju.edu.cn>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
---
 hw/display/ati_2d.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

+-- On Sun, 18 Oct 2020, BALATON Zoltan wrote --+
| The s->regs.[src|dst]_[xy] values should not be over 0x3fff because we mask 
| them on register write in ati.c

  Yes, those register values are set to zero(0).

| and here [src|dst]_[x|y] local variables are declared unsigned so negative 
| values come out as large integers that should be caught by the checks below 
| as being over VRAM end

  As above register values are zero(0), following expression(s)

    dst_x = ... (s->regs.dst_x(=0) + 1 - s->regs.dst_width(=16383))
    dst_y = ... (s->regs.dst_y(=0) + 1 - s->regs.dst_height(=16383))

result in large unsigned values: 

  ati_2d_blt
    pixman_blt(0x7f03cbe00000, 0x7f03cbe00000, 131064, 131064, 32, 32,
       src_x=0, src_y=-16382, dst_x=0, dst_y=-16382, 16383, 16383)

Shown as negative values due to signed '%d' conversion.

| but those checks may have an off by one error or some other mistake.

    uint8_t *end = s->vga.vram_ptr + s->vga.vram_size;
    if (dst_bits >= end || dst_bits + dst_x + (dst_y + s->regs.dst_height) * dst_stride >= end) {
        qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
        return;
    }

* Above check does not seem to catch it.

* Does a check below look okay?
===
diff --git a/hw/display/ati_2d.c b/hw/display/ati_2d.c
index 524bc03a83..b75acc7fda 100644
--- a/hw/display/ati_2d.c
+++ b/hw/display/ati_2d.c
@@ -54,9 +54,13 @@ void ati_2d_blt(ATIVGAState *s)
...
+    if (dst_x > 0x3fff || dst_y > 0x3fff) {
+        qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
+        return;
+    }
...
+        if (src_x > 0x3fff || src_y > 0x3fff) {
+            qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
+            return;
+        }
===

* ati_2d_blt() routine looks complex. Maybe it can be divided in two halves.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Hi,

+-- On Mon, 19 Oct 2020, BALATON Zoltan wrote --+
| On Mon, 19 Oct 2020, P J P wrote:
| >    dst_x = ... (s->regs.dst_x(=0) + 1 - s->regs.dst_width(=16383))
| >    dst_y = ... (s->regs.dst_y(=0) + 1 - s->regs.dst_height(=16383))
| >
| >  ati_2d_blt
| >    pixman_blt(0x7f03cbe00000, 0x7f03cbe00000, 131064, 131064, 32, 32,
| >       src_x=0, src_y=-16382, dst_x=0, dst_y=-16382, 16383, 16383)
| >
| > Shown as negative values due to signed '%d' conversion.
| 
| Checking the docs again I see that the allowed range of at least
| s->regs.[src|dst]_[xy] can actually be negative (-8192:8191)

* But 'struct ATIVGARegs' declares these fields as 'uint32_t' type. Ie. no 
  negativeve values.

* I guess that range applies to src->regs.dst_[width|height] too? Considering 
  it being subtracted from s->regs.dst_[xy] values above.


| >    uint8_t *end = s->vga.vram_ptr + s->vga.vram_size;
| >    if (dst_bits >= end || dst_bits + dst_x + (dst_y + s->regs.dst_height) *
| >    dst_stride >= end) {
| >        qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
| >        return;
| 
| ... Could it be it overflows?

* Yes, following expression

  dst_y(=4294950914(=-16382)) + s->regs.dst_height(=16383)) overflows to => 1

Ie. (dst_bits + dst_x(=0) + (1) * dst_stride >= end) returns false.


| maybe rather add additional term for src|dst_x|y to the already existing 
| checks if their condition cannot be fixed to detect it properly.
===
diff --git a/hw/display/ati_2d.c b/hw/display/ati_2d.c
index 524bc03a83..5fa7362305 100644
--- a/hw/display/ati_2d.c
+++ b/hw/display/ati_2d.c
@@ -54,9 +54,9 @@ void ati_2d_blt(ATIVGAState *s)
...
-    if (dst_bits >= end || dst_bits + dst_x + (dst_y + s->regs.dst_height) *
-        dst_stride >= end) {
+    if (dst_x > 0x3fff || dst_y > 0x3fff || dst_bits >= end
+        || dst_bits + dst_x + (dst_y + s->regs.dst_height)
+         * dst_stride >= end) {
         qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
         return;
     }
...
-        if (src_bits >= end || src_bits + src_x +
-            (src_y + s->regs.dst_height) * src_stride >= end) {
+        if (src_x > 0x3fff || src_y > 0x3ff || src_bits >= end
+            || src_bits + src_x + (src_y + s->regs.dst_height)
+             * src_stride >= end) {
             qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
             return;
         }
===

* Does it look okay?


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

+-- On Tue, 20 Oct 2020, BALATON Zoltan wrote --+
| The card has 32 bit registers with values in them interpreted differently for
| different regs. For dst_x|y lower 14 bits can be set and value should be
| interpreted as -8192:8191 according to docs. I've got this wrong because all
| guests I've tried did not actually use negative values. The Solaris driver I
| was recently shown not to work may use that so I plan to look at it and fix it
| when I'll have time. 
... 
| Docs aren't very clear on that but I think these cannot be negative so 
| 0:8191 is valid range because it mentions that also bits 0-13 (or maybe 
| 0-15, the docs have a lot of copy&paste errors) are valid but only 0-12 are 
| used for rectangles, 13-15 used only for trapezoids (which we don't 
| emulate). The docs are really bad so we have to guess and see what guest 
| drivers do most of the time.

* I see. Are the docs available/accessible online?

| >  dst_y(=4294950914(=-16382)) + s->regs.dst_height(=16383)) overflows to => 1
| > Ie. (dst_bits + dst_x(=0) + (1) * dst_stride >= end) returns false.
| 
| So maybe we should cast something (like dst_stride) to uint64_t here to
| promote everything to 64 bit and prevent it overflowing which then should
| catch this as well?
... 
| > +    if (dst_x > 0x3fff || dst_y > 0x3fff || dst_bits >= end
| > +        || dst_bits + dst_x + (dst_y + s->regs.dst_height)
| > +         * dst_stride >= end) {
| > ...
| > +        if (src_x > 0x3fff || src_y > 0x3ff || src_bits >= end
| > +            || src_bits + src_x + (src_y + s->regs.dst_height)
| > +             * src_stride >= end) {
| >             qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
| 
| I can live with that until I have a chance to rewrite it but are you sure this
| will catch all possible overflows with all vram sizes that can be set with
| vgamem_mb property?

* Considering all fields are 'uint32_t' type; And majority of the values 
  s->regs.[src|dst]_[xy], s->regs.dst_height are masked with '0x3fff', it 
  should help to avoid overflows.

* Not sure about all vram sizes. What are possible/supported size options?

* Between casting expression to 64 bits & explicit src_[xy] > 0x3fff check, 
  I'd go with explicit check, as it's easy to follow.

  Will send a revised patch with src_[xy] > 0x3fff if it's okay with you.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D