Bug #594: CAN-2005-2495: Fix exploitable integer overflow in pixmap

    creation, where we could create a far smaller pixmap than we thought,
    allowing changes to arbitrary chunks of memory. (Søren Sandmann
    Pedersen)

2 files changed, 20 insertions, 0 deletions

diff --git a/dix/dispatch.c b/dix/dispatch.c
index 99103ae65..ccbe06419 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -1483,6 +1483,23 @@ ProcCreatePixmap(register ClientPtr 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;
diff --git a/dix/pixmap.c b/dix/pixmap.c
index f76c557f4..78ce2a8c6 100644
--- a/dix/pixmap.c
+++ b/dix/pixmap.c
@@ -118,6 +118,9 @@ AllocatePixmap(ScreenPtr pScreen, int pixDataSize)
     unsigned size;
     int i;
 
+    if (pScreen->totalPixmapSize > ((size_t)-1) - pixDataSize)
+	return NullPixmap;
+    
     pPixmap = (PixmapPtr)xalloc(pScreen->totalPixmapSize + pixDataSize);
     if (!pPixmap)
 	return NullPixmap;