Rename patch: 008_nxproxy_add-nx-proxy-wrapper.patch to 008_nxproxy_add-nxproxy-wrapper.patch. Add patch from FreeNX patchset: 110_nxagent_createpixmap-bounds-check.patch.

1 files changed, 26 insertions, 0 deletions

diff --git a/debian/patches/110_nxagent_createpixmap-bounds-check.patch b/debian/patches/110_nxagent_createpixmap-bounds-check.patch
new file mode 100644
index 000000000..a5d4c3afa
--- /dev/null
+++ b/debian/patches/110_nxagent_createpixmap-bounds-check.patch
@@ -0,0 +1,26 @@
+--- 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;