From: Peter Lieven <pl@kamp.de>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, anthony@codemonkey.ws, xiawenc@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH] ui/vnc: fix potential memory corruption issues
Date: Mon, 30 Jun 2014 10:01:34 +0200 [thread overview]
Message-ID: <53B1195E.9060708@kamp.de> (raw)
In-Reply-To: <1404114779.24066.2.camel@nilsson.home.kraxel.org>
On 30.06.2014 09:52, Gerd Hoffmann wrote:
> On Mo, 2014-06-30 at 09:24 +0200, Peter Lieven wrote:
>> this patch addresses 2 memory corruption issues.
>>
>> The first was actually discovered during playing
>> around with a Windows 7 vServer. During resolution
>> change in Windows 7 it happens sometimes that Windows
>> changes to an intermediate resolution where
>> server_stride % cmp_bytes != 0 (in vnc_refresh_server_surface).
>> This happens only if width % VNC_DIRTY_PIXELS_PER_BIT != 0.
>> The patch fixes the issue by clamping cmp_bytes in that case
>> and it finally makes those resolutions work correctly.
>> This can be easily tested by setting VNC_DIRTY_PIXELS_PER_BIT
>> to a bigger power of 2 value different than 16.
>>
>> The second is a theoretical issue, but is maybe exploitable
>> by the guest. If for some reason the surface size is bigger
>> than VNC_MAX_WIDTH x VNC_MAX_HEIGHT we end up in severe corruption.
>> This can be easily reproduced by playing around with VNC_MAX_WIDTH
>> and VNC_MAX_HEIGHT. This patch modifies the VNC server to only
>> track and copy the area up to the maximum possible size.
> So this basically makes vnc work correctly in case guest surface and
> server surface have different sizes, then fixes the two bugs on top of
> that. And it obsoletes the other corruption patch send Friday.
> Correct?
Yes and yes.
Basically the server surface is adjusted to not exceed VNC_MAX_WIDTH x VNC_MAX_HEIGHT
and on top the width is rounded up to multiple of VNC_DIRTY_PIXELS_PER_BIT.
If you have a resolution whose width is not dividable by VNC_DIRTY_PIXELS_PER_BIT you get
a small black bar on the right of the screen. First I wanted to fix only that and then
I noticed that VNC_MAX_WIDTH and VNC_MAX_HEIGHT are nowhere enforced. I do not
know if this is actually exploitable by the guest.
If the surface is too big to fit the limits only the upper left area is shown.
I ran several sessions with altered values of VNC_MAX_WIDTH, VNC_MAX_HEIGHT and VNC_DIRTY_PIXELS_PER_BIT
in valgrind, but additional testing is welcome.
Peter
next prev parent reply other threads:[~2014-06-30 8:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 7:24 [Qemu-devel] [PATCH] ui/vnc: fix potential memory corruption issues Peter Lieven
2014-06-30 7:52 ` Gerd Hoffmann
2014-06-30 8:01 ` Peter Lieven [this message]
2014-06-30 8:35 ` 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=53B1195E.9060708@kamp.de \
--to=pl@kamp.de \
--cc=anthony@codemonkey.ws \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xiawenc@linux.vnet.ibm.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 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.