qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ati: mask x y display parameter values


From: P J P
Subject: Re: [PATCH] ati: mask x y display parameter values
Date: Mon, 19 Oct 2020 11:57:37 +0530 (IST)

+-- 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]