aboutsummaryrefslogtreecommitdiff
path: root/debian/patches/0110_nxagent_createpixmap-bounds-check.full.patch
blob: 1062319838d83f1e936c65f2a7dc09dc8e56ab30 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
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 @@ 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;