From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeihW-0001q6-5w for qemu-devel@nongnu.org; Thu, 16 Oct 2014 06:54:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XeihO-0005vi-1Y for qemu-devel@nongnu.org; Thu, 16 Oct 2014 06:54:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeihN-0005vV-Pg for qemu-devel@nongnu.org; Thu, 16 Oct 2014 06:54:25 -0400 Message-ID: <1413456861.18160.3.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Thu, 16 Oct 2014 12:54:21 +0200 In-Reply-To: <543E961E.4090309@msgid.tls.msk.ru> References: <1413367839-30999-1-git-send-email-kraxel@redhat.com> <543E961E.4090309@msgid.tls.msk.ru> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/5] vmware-vga: fix CVE-2014-3689 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: pmatouse@redhat.com, qemu-devel@nongnu.org, Intel.Product.Security.Incident.Response.Team@intel.com On Mi, 2014-10-15 at 17:43 +0200, Michael Tokarev wrote: > On 15.10.2014 12:10, Gerd Hoffmann wrote: > > Hi, > > > > vmware-vga emulation lacks sanity checks in the hardware acceleration > > (blit + fill) functions. This patch series plugs the holes. > > > > v2 changes: > > * small whitespace fixup. > > * do fullscreen update on invalid update requests. > > > > cheers, > > Gerd > > > > Gerd Hoffmann (5): > > vmware-vga: CVE-2014-3689: turn off hw accel > > vmware-vga: add vmsvga_verify_rect > > vmware-vga: use vmsvga_verify_rect in vmsvga_update_rect > > vmware-vga: use vmsvga_verify_rect in vmsvga_copy_rect > > vmware-vga: use vmsvga_verify_rect in vmsvga_fill_rect > > A small question. Why do you first disable the hw accel for rect&fill > and re-enable them in subsequent patches, as if applying the real > fix patches takes very long time and during that time we need the > hole to be fixed? That was just the order the patches where created. There isn't a real need for patch #1, but it didn't look important enough to me to bother fixing it up after the series was complete. cheers, Gerd