qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
	Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: qemu-devel@nongnu.org, Li Qiang <liqiang6-s@360.cn>,
	qemu-stable@nongnu.org, P J P <ppandit@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] cirrus: fix oob access issue (CVE-2017-TODO)
Date: Wed, 25 Jan 2017 11:35:44 +0100	[thread overview]
Message-ID: <5322aaff-c5c6-694b-6206-d6bf729ae6f9@redhat.com> (raw)
In-Reply-To: <1485337815.29826.103.camel@redhat.com>

On 01/25/17 10:50, Gerd Hoffmann wrote:
> On Mi, 2017-01-25 at 09:30 +0100, Wolfgang Bumiller wrote:
>> On Wed, Jan 25, 2017 at 08:07:05AM +0100, Gerd Hoffmann wrote:
>>> From: Li Qiang <liqiang6-s@360.cn>
>>>
>>> When doing bitblt copy in backward mode, we should minus the
>>> blt width first just like the adding in the forward mode. This
>>> can avoid the oob access of the front of vga's vram.
>>>
>>> Signed-off-by: Li Qiang <liqiang6-s@360.cn>
>>> Message-id: 5887254f.863a240a.2c122.5500@mx.google.com
>>>
>>> { kraxel: with backward blits (negative pitch) addr is the topmost
>>>           address, so check it as-is against vram size ]
>>>
>>> Cc: qemu-stable@nongnu.org
>>> Cc: P J P <ppandit@redhat.com>
>>> Cc: Laszlo Ersek <lersek@redhat.com>
>>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>>> Cc: Wolfgang Bumiller <w.bumiller@proxmox.com>
>>> Fixes: d3532a0db02296e687711b8cdc7791924efccea0 (CVE-2014-8106)
>>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>>> ---
>>>  hw/display/cirrus_vga.c | 7 +++----
>>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
>>> index 379910d..b8c29a6 100644
>>> --- a/hw/display/cirrus_vga.c
>>> +++ b/hw/display/cirrus_vga.c
>>> @@ -277,10 +277,9 @@ static bool blit_region_is_unsafe(struct CirrusVGAState *s,
>>>      }
>>>      if (pitch < 0) {
>>>          int64_t min = addr
>>> -            + ((int64_t)s->cirrus_blt_height-1) * pitch;
>>> -        int32_t max = addr
>>> -            + s->cirrus_blt_width;
>>> -        if (min < 0 || max > s->vga.vram_size) {
>>> +            + ((int64_t)s->cirrus_blt_height - 1) * pitch
>>> +            - s->cirrus_blt_width;
>>> +        if (min < 0 || addr > s->vga.vram_size) {
>>
>> Call me paranoid, but shouldn't this be '>='? Missed this yesterday
>> apparently, correct me if I'm wrong:
>> If VRAM goes from 0..7 it has a size of 8, and this would accept
>> address 8 as it's not > size.
> 
> I think you are right.  The bkwd ops first execute the op, then
> decrement, so addr is inclusive and the check is off by one.

That's right IMO; however, in that case we also have to posit that "min"
is exclusive. Assume that we have 16 pixels in the VGA memory (4x4), and
that we are massaging the bottom right quadrant:

   0  1  2  3
   4  5  6  7
   8  9 10 11
  12 13 14 15

  addr   =  15
  height =   2
  width  =   2
  pitch  =  -4

Then

  min = addr + (height - 1) * pitch - width
      =   15 + (     2 - 1) * (-4)  - 2
      = 9

Which is the address right before the top left pixel; that is, it marks
the first pixel *not* accessed.

If that value was (-1), then the operation would still be valid.

So we should accept (min == -1) -- this is dictated by plain symmetry.
If "max" -- here, "addr" -- is inclusive, then "min" becomes exclusive.

Thanks
Laszlo

  reply	other threads:[~2017-01-25 10:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25  7:07 [Qemu-devel] [PATCH] cirrus: fix oob access issue (CVE-2017-TODO) Gerd Hoffmann
2017-01-25  8:30 ` Wolfgang Bumiller
2017-01-25  9:50   ` Gerd Hoffmann
2017-01-25 10:35     ` Laszlo Ersek [this message]
2017-01-25 10:50       ` Wolfgang Bumiller
2017-01-25 10:55         ` Laszlo Ersek
2017-01-25 10:44 ` Gerd Hoffmann

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=5322aaff-c5c6-694b-6206-d6bf729ae6f9@redhat.com \
    --to=lersek@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=liqiang6-s@360.cn \
    --cc=pbonzini@redhat.com \
    --cc=ppandit@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=w.bumiller@proxmox.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 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).