Commit 47122390 authored by Mike Gabriel's avatar Mike Gabriel

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
parent 223f5548
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;
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
......
......@@ -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;
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment