aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--debian/patches/110_nxagent_createpixmap-bounds-check.full.patch44
-rw-r--r--debian/patches/series1
-rw-r--r--nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c17
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 d65862bdc..000000000
--- 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@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 c904d1894..5a5a30e08 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 4f59b8098..77e2bf473 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;