[X2Go-Commits] [nx-libs] 09/24: Avoid large pixmaps (110_nxagent_createpixmap-bounds-check.full.patch).

[git-admin at x2go.org]

This is an automated email from the git hooks/post-receive script.

x2go pushed a commit to branch 3.6.x
in repository nx-libs.

commit 471223907081355a288a315b33a2b70eb4c8fb1e
Author: Mike Gabriel <mike.gabriel at das-netzwerkteam.de>
Date:   Tue Feb 10 19:17:58 2015 +0100

    Avoid large pixmaps (110_nxagent_createpixmap-bounds-check.full.patch).
    
      It is allowed to try and allocate a pixmap which is larger than
      32767 in either dimension. However, all of the framebuffer code
      is buggy and does not reliably draw to such big pixmaps, basically
      because the Region data structure operates with signed shorts
      for the rectangles in it.
    
      Furthermore, several places in the X server computes the
      size in bytes of the pixmap and tries to store it in an
      integer. This integer can overflow and cause the allocated size
      to be much smaller.
    
      So, such big pixmaps are rejected here with a BadAlloc
    
      Originally contributed by FreeNX Team
---
 ...10_nxagent_createpixmap-bounds-check.full.patch |   44 --------------------
 debian/patches/series                              |    1 -
 nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c    |   17 ++++++++
 3 files changed, 17 insertions(+), 45 deletions(-)

diff --git a/debian/patches/110_nxagent_createpixmap-bounds-check.full.patch b/debian/patches/110_nxagent_createpixmap-bounds-check.full.patch
deleted file mode 100644
index d65862b..0000000
--- a/debian/patches/110_nxagent_createpixmap-bounds-check.full.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-Description: Avoid large pixmaps
- It is allowed to try and allocate a pixmap which is larger than
- 32767 in either dimension. However, all of the framebuffer code
- is buggy and does not reliably draw to such big pixmaps, basically
- because the Region data structure operates with signed shorts
- for the rectangles in it.
- .
- Furthermore, several places in the X server computes the
- size in bytes of the pixmap and tries to store it in an
- integer. This integer can overflow and cause the allocated size
- to be much smaller.
- .
- So, such big pixmaps are rejected here with a BadAlloc
- .
- Originally contributed by FreeNX Team
-Forwarded: pending...
-Author: Mike Gabriel <mike.gabriel at das-netzwerkteam.de>
-Last-Update: 2011-12-31
---- a/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c
-+++ b/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c
-@@ -1973,6 +1973,23 @@
- 	client->errorValue = 0;
-         return BadValue;
-     }
-+    if (stuff->width > 32767 || stuff->height > 32767)
-+    {
-+	/* It is allowed to try and allocate a pixmap which is larger than
-+	 * 32767 in either dimension. However, all of the framebuffer code
-+	 * is buggy and does not reliably draw to such big pixmaps, basically
-+	 * because the Region data structure operates with signed shorts
-+	 * for the rectangles in it.
-+	 *
-+	 * Furthermore, several places in the X server computes the
-+	 * size in bytes of the pixmap and tries to store it in an
-+	 * integer. This integer can overflow and cause the allocated size
-+	 * to be much smaller.
-+	 *
-+	 * So, such big pixmaps are rejected here with a BadAlloc
-+	 */
-+	return BadAlloc;
-+    }
-     if (stuff->depth != 1)
-     {
-         pDepth = pDraw->pScreen->allowedDepths;
diff --git a/debian/patches/series b/debian/patches/series
index c904d18..5a5a30e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,4 +1,3 @@
-110_nxagent_createpixmap-bounds-check.full.patch
 200_nxagent_check-binary-x2go-flavour.full.patch
 201_nxagent_set-x2go-icon-if-x2goagent-flavour.full.patch
 202_nx-X11_enable-xinerama.full.patch
diff --git a/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c b/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c
index 4f59b80..77e2bf4 100644
--- a/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c
+++ b/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c
@@ -1973,6 +1973,23 @@ ProcCreatePixmap(client)
 	client->errorValue = 0;
         return BadValue;
     }
+    if (stuff->width > 32767 || stuff->height > 32767)
+    {
+	/* It is allowed to try and allocate a pixmap which is larger than
+	 * 32767 in either dimension. However, all of the framebuffer code
+	 * is buggy and does not reliably draw to such big pixmaps, basically
+	 * because the Region data structure operates with signed shorts
+	 * for the rectangles in it.
+	 *
+	 * Furthermore, several places in the X server computes the
+	 * size in bytes of the pixmap and tries to store it in an
+	 * integer. This integer can overflow and cause the allocated size
+	 * to be much smaller.
+	 *
+	 * So, such big pixmaps are rejected here with a BadAlloc
+	 */
+	return BadAlloc;
+    }
     if (stuff->depth != 1)
     {
         pDepth = pDraw->pScreen->allowedDepths;

--
Alioth's /srv/git/_hooks_/post-receive-email on /srv/git/code.x2go.org/nx-libs.git