[PATCH xf86-video-dummy 3/4] Remove DGA support

2016-12-06 Thread Bob Terek
DGA was so 2004.

Signed-off-by: Bob Terek 
---
 configure.ac   |   8 ---
 src/Makefile.am|   5 --
 src/dummy.h|   7 ---
 src/dummy_dga.c| 175 -
 src/dummy_driver.c |   8 ---
 5 files changed, 203 deletions(-)
 delete mode 100644 src/dummy_dga.c

diff --git a/configure.ac b/configure.ac
index e6e0043..cc25cfd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -46,7 +46,6 @@ AC_PROG_LIBTOOL
 AH_TOP([#include "xorg-server.h"])
 
 # Define a configure option for an alternate module directory
-AC_ARG_ENABLE(dga,   AS_HELP_STRING([--disable-dga], [Build DGA 
extension (default: yes)]), [DGA=$enableval], [DGA=yes])
 AC_ARG_WITH(xorg-module-dir, [  --with-xorg-module-dir=DIR ],
  [ moduledir="$withval" ],
  [ moduledir="$libdir/xorg/modules" ])
@@ -57,13 +56,6 @@ AC_SUBST(moduledir)
 XORG_DRIVER_CHECK_EXT(RANDR, randrproto)
 XORG_DRIVER_CHECK_EXT(RENDER, renderproto)
 
-if test "x$DGA" = xyes; then
-   XORG_DRIVER_CHECK_EXT(XFreeXDGA, xf86dgaproto)
-   AC_DEFINE(USE_DGA, 1, [Support DGA extension])
-fi
-AC_SUBST([DGA])
-AM_CONDITIONAL([DGA], [test "x$DGA" = xyes])
-
 # Obtain compiler/linker options for the driver dependencies
 PKG_CHECK_MODULES(XORG, [xorg-server >= 1.0.99.901] xproto fontsproto 
$REQUIRED_MODULES)
 
diff --git a/src/Makefile.am b/src/Makefile.am
index da1dd9a..c0d82e0 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -37,8 +37,3 @@ dummy_drv_la_SOURCES = \
  dummy_cursor.c \
  dummy_driver.c \
  dummy.h
-
-if DGA
-dummy_drv_la_SOURCES +=\
- dummy_dga.c
-endif
diff --git a/src/dummy.h b/src/dummy.h
index 705b9e5..f902fa6 100644
--- a/src/dummy.h
+++ b/src/dummy.h
@@ -28,9 +28,6 @@ extern Bool DUMMYCursorInit(ScreenPtr pScrn);
 extern void DUMMYShowCursor(ScrnInfoPtr pScrn);
 extern void DUMMYHideCursor(ScrnInfoPtr pScrn);
 
-/* in dummy_dga.c */
-Bool DUMMYDGAInit(ScreenPtr pScreen);
-
 /* globals */
 typedef struct _color
 {
@@ -41,10 +38,6 @@ typedef struct _color
 
 typedef struct dummyRec 
 {
-DGAModePtr DGAModes;
-intnumDGAModes;
-Bool   DGAactive;
-intDGAViewportStatus;
 /* options */
 OptionInfoPtr Options;
 Bool swCursor;
diff --git a/src/dummy_dga.c b/src/dummy_dga.c
deleted file mode 100644
index d16d09f..000
--- a/src/dummy_dga.c
+++ /dev/null
@@ -1,175 +0,0 @@
-#ifdef HAVE_CONFIG_H
-#include "config.h"
-#endif
-
-#include "xf86.h"
-#include "xf86_OSproc.h"
-#include "dgaproc.h"
-#include "dummy.h"
-
-static Bool DUMMY_OpenFramebuffer(ScrnInfoPtr, char **, unsigned char **, 
-   int *, int *, int *);
-static Bool DUMMY_SetMode(ScrnInfoPtr, DGAModePtr);
-static int  DUMMY_GetViewport(ScrnInfoPtr);
-static void DUMMY_SetViewport(ScrnInfoPtr, int, int, int);
-
-static
-DGAFunctionRec DUMMYDGAFuncs = {
-   DUMMY_OpenFramebuffer,
-   NULL,
-   DUMMY_SetMode,
-   DUMMY_SetViewport,
-   DUMMY_GetViewport,
-   NULL,
-   NULL,
-   NULL,
-#if 0
-   DUMMY_BlitTransRect
-#else
-   NULL
-#endif
-};
-
-Bool
-DUMMYDGAInit(ScreenPtr pScreen)
-{   
-   ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
-   DUMMYPtr pDUMMY = DUMMYPTR(pScrn);
-   DGAModePtr modes = NULL, newmodes = NULL, currentMode;
-   DisplayModePtr pMode, firstMode;
-   int Bpp = pScrn->bitsPerPixel >> 3;
-   int num = 0, imlines, pixlines;
-
-   imlines =  (pScrn->videoRam * 1024) /
-  (pScrn->displayWidth * (pScrn->bitsPerPixel >> 3));
-
-   pixlines =   imlines;
-
-   pMode = firstMode = pScrn->modes;
-
-   while(pMode) {
-
-   newmodes = realloc(modes, (num + 1) * sizeof(DGAModeRec));
-
-   if(!newmodes) {
-  free(modes);
-  return FALSE;
-   }
-   modes = newmodes;
-
-   currentMode = modes + num;
-   num++;
-
-   currentMode->mode = pMode;
-   currentMode->flags = DGA_CONCURRENT_ACCESS | DGA_PIXMAP_AVAILABLE;
-   if(pMode->Flags & V_DBLSCAN)
-  currentMode->flags |= DGA_DOUBLESCAN;
-   if(pMode->Flags & V_INTERLACE)
-  currentMode->flags |= DGA_INTERLACED;
-   currentMode->byteOrder = pScrn->imageByteOrder;
-   currentMode->depth = pScrn->depth;
-   currentMode->bitsPerPixel = pScrn->bitsPerPixel;
-   currentMode->red_mask = pScrn->mask.red;
-   currentMode->green_mask = pScrn->mask.green;
-   currentMode->blue_mask = pScrn->mask.blue;
-   currentMode->visualClass = (Bpp == 1) ? PseudoColor : TrueColor;
-   currentMode->viewportWidth = pMode->HDisplay;
-   currentMode->viewportHeight = pMode->VDisplay;
-   currentMode->xViewportStep = 1;
-   currentMode->yViewportStep = 1;
-   currentMode->viewportFlags = DGA_FLIP_RETRACE;
-   currentMode->offset = 0;
-   currentMode->address = (unsigned char *)pDUMMY->FBBase;
-
-   currentMode->bytesPerScanline = 
-  

[PATCH xf86-video-dummy 4/4] Get rid of dPtr->FBBase

2016-12-06 Thread Bob Terek
The pointer to the screen's pixels is stored in the screen pixmap's
devPrivate.ptr field.  Just use that instead of storing it
redundantly.

In addition, don't leak the screen if the server was VT switched.

Signed-off-by: Bob Terek 
---
 src/dummy.h|  1 -
 src/dummy_cursor.c |  2 --
 src/dummy_driver.c | 11 +--
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/src/dummy.h b/src/dummy.h
index f902fa6..82fbdea 100644
--- a/src/dummy.h
+++ b/src/dummy.h
@@ -50,7 +50,6 @@ typedef struct dummyRec
 int cursorFG, cursorBG;
 
 dummy_colors colors[256];
-pointer* FBBase;
 Bool(*CreateWindow)() ; /* wrapped CreateWindow */
 Bool prop;
 } DUMMYRec, *DUMMYPtr;
diff --git a/src/dummy_cursor.c b/src/dummy_cursor.c
index 07a89bf..d7c67c6 100644
--- a/src/dummy_cursor.c
+++ b/src/dummy_cursor.c
@@ -39,8 +39,6 @@ dummySetCursorPosition(ScrnInfoPtr pScrn, int x, int y)
 {
 DUMMYPtr dPtr = DUMMYPTR(pScrn);
 
-/* unsigned char *_dest = ((unsigned char *)dPtr->FBBase + */
-/* pScrn->videoRam * 1024 - 1024); */
 dPtr->cursorX = x;
 dPtr->cursorY = y;
 }
diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 6653883..03fa1d7 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -501,7 +501,8 @@ DUMMYScreenInit(SCREEN_INIT_ARGS_DECL)
 DUMMYPtr dPtr;
 int ret;
 VisualPtr visual;
-
+void *pixels;
+
 /*
  * we need to get the ScrnInfoRec for this screen, so let's allocate
  * one first thing
@@ -511,7 +512,7 @@ DUMMYScreenInit(SCREEN_INIT_ARGS_DECL)
 DUMMYScrn = pScrn;
 
 
-if (!(dPtr->FBBase = malloc(pScrn->videoRam * 1024)))
+if (!(pixels = malloc(pScrn->videoRam * 1024)))
return FALSE;
 
 /*
@@ -532,7 +533,7 @@ DUMMYScreenInit(SCREEN_INIT_ARGS_DECL)
  * Call the framebuffer layer's ScreenInit function, and fill in other
  * pScreen fields.
  */
-ret = fbScreenInit(pScreen, dPtr->FBBase,
+ret = fbScreenInit(pScreen, pixels,
pScrn->virtualX, pScrn->virtualY,
pScrn->xDpi, pScrn->yDpi,
pScrn->displayWidth, pScrn->bitsPerPixel);
@@ -644,9 +645,7 @@ DUMMYCloseScreen(CLOSE_SCREEN_ARGS_DECL)
 ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
 DUMMYPtr dPtr = DUMMYPTR(pScrn);
 
-if(pScrn->vtSema){
-   free(dPtr->FBBase);
-}
+free(pScreen->GetScreenPixmap(pScreen)->devPrivate.ptr);
 
 if (dPtr->CursorInfo)
xf86DestroyCursorInfoRec(dPtr->CursorInfo);
-- 
1.9.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-video-dummy 2/4] Delete dPtr->screenSaver

2016-12-06 Thread Bob Terek
This is assigned, but never used.

Signed-off-by: Bob Terek 
---
 src/dummy.h| 1 -
 src/dummy_driver.c | 9 -
 2 files changed, 10 deletions(-)

diff --git a/src/dummy.h b/src/dummy.h
index c231be4..705b9e5 100644
--- a/src/dummy.h
+++ b/src/dummy.h
@@ -56,7 +56,6 @@ typedef struct dummyRec
 int cursorX, cursorY;
 int cursorFG, cursorBG;
 
-Bool screenSaver;
 dummy_colors colors[256];
 pointer* FBBase;
 Bool(*CreateWindow)() ; /* wrapped CreateWindow */
diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index c9ff925..24f2f28 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -675,15 +675,6 @@ DUMMYFreeScreen(FREE_SCREEN_ARGS_DECL)
 static Bool
 DUMMYSaveScreen(ScreenPtr pScreen, int mode)
 {
-ScrnInfoPtr pScrn = NULL;
-DUMMYPtr dPtr;
-
-if (pScreen != NULL) {
-   pScrn = xf86ScreenToScrn(pScreen);
-   dPtr = DUMMYPTR(pScrn);
-
-   dPtr->screenSaver = xf86IsUnblank(mode);
-} 
 return TRUE;
 }
 
-- 
1.9.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-video-dummy 0/4] Cleanups Redux

2016-12-06 Thread Bob Terek
Resubmitting some of Aaron Plattner's cleanup patches to xf86-video-dummy:

  https://lists.x.org/archives/xorg-devel/2015-January/045395.html

This series contains Aaron's patches numbered 2 - 5, as patch 1 has already
been applied, and patch 6 introduced new functionality.

Bob Terek (4):
  Delete XV stuff   (Aaron's patch 2/6)
  Delete dPtr->screenSaver  (Aaron's patch 3/6)
  Remove DGA support(Aaron's patch 4/6)
  Get rid of dPtr->FBBase   (Aaron's patch 5/6)

 configure.ac   |   9 ---
 src/Makefile.am|   5 --
 src/dummy.h|  20 --
 src/dummy_cursor.c |   2 -
 src/dummy_dga.c| 175 -
 src/dummy_driver.c |  35 ++-
 6 files changed, 5 insertions(+), 241 deletions(-)
 delete mode 100644 src/dummy_dga.c

-- 
1.9.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-video-dummy 1/4] Delete XV stuff

2016-12-06 Thread Bob Terek
As far as anyone can tell, this was never implemented or used.

Signed-off-by: Bob Terek 
---
 configure.ac   |  1 -
 src/dummy.h| 11 ---
 src/dummy_driver.c |  7 ---
 3 files changed, 19 deletions(-)

diff --git a/configure.ac b/configure.ac
index 005611d..e6e0043 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,7 +56,6 @@ AC_SUBST(moduledir)
 # Store the list of server defined optional extensions in REQUIRED_MODULES
 XORG_DRIVER_CHECK_EXT(RANDR, randrproto)
 XORG_DRIVER_CHECK_EXT(RENDER, renderproto)
-XORG_DRIVER_CHECK_EXT(XV, videoproto)
 
 if test "x$DGA" = xyes; then
XORG_DRIVER_CHECK_EXT(XFreeXDGA, xf86dgaproto)
diff --git a/src/dummy.h b/src/dummy.h
index c3fdd6e..c231be4 100644
--- a/src/dummy.h
+++ b/src/dummy.h
@@ -31,9 +31,6 @@ extern void DUMMYHideCursor(ScrnInfoPtr pScrn);
 /* in dummy_dga.c */
 Bool DUMMYDGAInit(ScreenPtr pScreen);
 
-/* in dummy_video.c */
-extern void DUMMYInitVideo(ScreenPtr pScreen);
-
 /* globals */
 typedef struct _color
 {
@@ -60,14 +57,6 @@ typedef struct dummyRec
 int cursorFG, cursorBG;
 
 Bool screenSaver;
-Bool video;
-#ifdef XvExtension
-XF86VideoAdaptorPtr overlayAdaptor;
-#endif
-int overlay;
-int overlay_offset;
-int videoKey;
-int interlace;
 dummy_colors colors[256];
 pointer* FBBase;
 Bool(*CreateWindow)() ; /* wrapped CreateWindow */
diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 2656602..c9ff925 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -29,11 +29,6 @@
 
 #include "picturestr.h"
 
-#ifdef XvExtension
-#include "xf86xv.h"
-#include 
-#endif
-
 /*
  * Driver data structures.
  */
@@ -618,8 +613,6 @@ DUMMYScreenInit(SCREEN_INIT_ARGS_DECL)
 | CMAP_RELOAD_ON_MODE_SWITCH))
return FALSE;
 
-/* DUMMYInitVideo(pScreen); */
-
 pScreen->SaveScreen = DUMMYSaveScreen;
 
 
-- 
1.9.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] composite: Fix repaint of borders (v2)

2016-12-06 Thread Keith Packard
Adam Jackson  writes:

> When going from border width zero to a non-zero border width, the
> Composite extension is informed via the ConfigNotify callback. The
> call-chain looks like this: compConfigNotify -> compReallocPixmap ->
> compSetPixmap -> TraverseTree -> compSetPixmapVisitWindow. However, at
> this time, pWindow->borderWidth was not yet updated. Thus, HasBorder()
> is false and the window border will not be repainted.
>
> To fix this, thread the new bw through to the window visitor, and
> inspect that rather than HasBorder(). For all the other callers the
> border does not change size, so we can pass pWin->borderWidth instead.

Yeah, that's a nicer version of this patch.

Reviewed-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXpm] Gracefully handle EOF while parsing files.

2016-12-06 Thread Matthieu Herrb
On Tue, Dec 06, 2016 at 10:34:33PM +0100, Matthieu Herrb wrote:

This is from https://bugs.freedesktop.org/show_bug.cgi?id=98878

> From: Tobias Stoeckmann 
> 
> libXpm does not properly handle EOF conditions when xpmGetC is called
> multiple times in a row to construct a string. Instead of checking
> its return value for EOF, the result is automatically casted into a
> char and attached to a string.
> 
> By carefully crafting the color table in an XPM file, it is possible to
> send a libXpm program like gimp into a very long lasting loop and
> massive memory allocations.
> 
> Otherwise no memory issues arise, therefore this is just a purely
> functional patch to dismiss invalid input.
> ---
>  src/parse.c | 40 
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/src/parse.c b/src/parse.c
> index ff23a47..c19209c 100644
> --- a/src/parse.c
> +++ b/src/parse.c
> @@ -234,8 +234,14 @@ xpmParseColors(
>   xpmFreeColorTable(colorTable, ncolors);
>   return (XpmNoMemory);
>   }
> - for (b = 0, s = color->string; b < cpp; b++, s++)
> - *s = xpmGetC(data);
> + for (b = 0, s = color->string; b < cpp; b++, s++) {
> + int c = xpmGetC(data);
> + if (c < 0) {
> + xpmFreeColorTable(colorTable, ncolors);
> + return (XpmFileInvalid);
> + }
> + *s = (char) c;
> + }
>   *s = '\0';
>  
>   /*
> @@ -322,8 +328,14 @@ xpmParseColors(
>   xpmFreeColorTable(colorTable, ncolors);
>   return (XpmNoMemory);
>   }
> - for (b = 0, s = color->string; b < cpp; b++, s++)
> - *s = xpmGetC(data);
> + for (b = 0, s = color->string; b < cpp; b++, s++) {
> + int c = xpmGetC(data);
> + if (c < 0) {
> + xpmFreeColorTable(colorTable, ncolors);
> + return (XpmFileInvalid);
> + }
> + *s = (char) c;
> + }
>   *s = '\0';
>  
>   /*
> @@ -505,8 +517,14 @@ do \
>   for (y = 0; y < height; y++) {
>   xpmNextString(data);
>   for (x = 0; x < width; x++, iptr++) {
> - for (a = 0, s = buf; a < cpp; a++, s++)
> - *s = xpmGetC(data); /* int assigned to char, not a 
> problem here */
> + for (a = 0, s = buf; a < cpp; a++, s++) {
> + int c = xpmGetC(data);
> + if (c < 0) {
> + XpmFree(iptr2);
> + return (XpmFileInvalid);
> + }
> + *s = (char) c;
> + }
>   slot = xpmHashSlot(hashtable, buf);
>   if (!*slot) {   /* no color matches */
>   XpmFree(iptr2);
> @@ -519,8 +537,14 @@ do \
>   for (y = 0; y < height; y++) {
>   xpmNextString(data);
>   for (x = 0; x < width; x++, iptr++) {
> - for (a = 0, s = buf; a < cpp; a++, s++)
> - *s = xpmGetC(data); /* int assigned to char, not a 
> problem here */
> + for (a = 0, s = buf; a < cpp; a++, s++) {
> + int c = xpmGetC(data);
> + if (c < 0) {
> + XpmFree(iptr2);
> + return (XpmFileInvalid);
> + }
> + *s = (char) c;
> + }
>   for (a = 0; a < ncolors; a++)
>   if (!strcmp(colorTable[a].string, buf))
>   break;
> -- 
> 2.10.2
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

-- 
Matthieu Herrb


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXpm] Fix out out boundary read on unknown colors

2016-12-06 Thread Matthieu Herrb
On Tue, Dec 06, 2016 at 10:31:53PM +0100, Matthieu Herrb wrote:

This is from https://bugs.freedesktop.org/show_bug.cgi?id=98877

> From: Tobias Stoeckmann 
> 
> libXpm is vulnerable to an out of boundary read if an XPM file contains
> a color with a symbolic name but without any default color value.
> 
> A caller must set XpmColorSymbols and a color with a NULL name in
> the supplied XpmAttributes to XpmReadFileToImage (or other functions of
> this type) in order to trigger this issue.
> ---
>  src/create.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/create.c b/src/create.c
> index d013da9..a750846 100644
> --- a/src/create.c
> +++ b/src/create.c
> @@ -647,7 +647,8 @@ CreateColors(
>   while (def_index <= 5 && defaults[def_index] == NULL)
>   ++def_index;
>   }
> - if (def_index >= 2 && defaults[def_index] != NULL &&
> + if (def_index >= 2 && def_index <= 5 &&
> + defaults[def_index] != NULL &&
>   !xpmstrcasecmp(symbol->value, defaults[def_index]))
>   break;
>   }
> -- 
> 2.10.2
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

-- 
Matthieu Herrb


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [patch libICE] Fix use after free on subsequent calls

2016-12-06 Thread Matthieu Herrb
On Tue, Dec 06, 2016 at 10:26:59PM +0100, Matthieu Herrb wrote:

This is from https://bugs.freedesktop.org/show_bug.cgi?id=98822

> From: Tobias Stoeckmann 
> 
> The function IceAuthFileName is vulnerable to a use after free. The
> flaw can be triggered by calling the function three times:
> 
> - First call succeeds and stores the path in buf, a dynamically
>   allocated buffer with size bsize.
> - Second call fails due to out of memory. It frees buf, but keeps
>   the old size in bsize.
> - Third call only checks if bsize is large enough. Then it uses
>   buf without allocating it again -- the use after free happens.
> 
> In order to exploit this, an attacker must change environment variables
> between each call, namely ICEAUTHORITY or HOME. It also takes subsequent
> calls. Due to these limitations, I don't consider this to be of high
> priority.
> ---
>  src/authutil.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git src/authutil.c src/authutil.c
> index 04c0791..ca0504a 100644
> --- src/authutil.c
> +++ src/authutil.c
> @@ -114,8 +114,10 @@ IceAuthFileName (void)
>   if (buf)
>   free (buf);
>   buf = malloc (size);
> - if (!buf)
> + if (!buf) {
> + bsize = 0;
>   return (NULL);
> + }
>   bsize = size;
>  }
>  
> -- 
> 2.10.2
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

-- 
Matthieu Herrb


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libXpm] Gracefully handle EOF while parsing files.

2016-12-06 Thread Matthieu Herrb
From: Tobias Stoeckmann 

libXpm does not properly handle EOF conditions when xpmGetC is called
multiple times in a row to construct a string. Instead of checking
its return value for EOF, the result is automatically casted into a
char and attached to a string.

By carefully crafting the color table in an XPM file, it is possible to
send a libXpm program like gimp into a very long lasting loop and
massive memory allocations.

Otherwise no memory issues arise, therefore this is just a purely
functional patch to dismiss invalid input.
---
 src/parse.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/src/parse.c b/src/parse.c
index ff23a47..c19209c 100644
--- a/src/parse.c
+++ b/src/parse.c
@@ -234,8 +234,14 @@ xpmParseColors(
xpmFreeColorTable(colorTable, ncolors);
return (XpmNoMemory);
}
-   for (b = 0, s = color->string; b < cpp; b++, s++)
-   *s = xpmGetC(data);
+   for (b = 0, s = color->string; b < cpp; b++, s++) {
+   int c = xpmGetC(data);
+   if (c < 0) {
+   xpmFreeColorTable(colorTable, ncolors);
+   return (XpmFileInvalid);
+   }
+   *s = (char) c;
+   }
*s = '\0';
 
/*
@@ -322,8 +328,14 @@ xpmParseColors(
xpmFreeColorTable(colorTable, ncolors);
return (XpmNoMemory);
}
-   for (b = 0, s = color->string; b < cpp; b++, s++)
-   *s = xpmGetC(data);
+   for (b = 0, s = color->string; b < cpp; b++, s++) {
+   int c = xpmGetC(data);
+   if (c < 0) {
+   xpmFreeColorTable(colorTable, ncolors);
+   return (XpmFileInvalid);
+   }
+   *s = (char) c;
+   }
*s = '\0';
 
/*
@@ -505,8 +517,14 @@ do \
for (y = 0; y < height; y++) {
xpmNextString(data);
for (x = 0; x < width; x++, iptr++) {
-   for (a = 0, s = buf; a < cpp; a++, s++)
-   *s = xpmGetC(data); /* int assigned to char, not a 
problem here */
+   for (a = 0, s = buf; a < cpp; a++, s++) {
+   int c = xpmGetC(data);
+   if (c < 0) {
+   XpmFree(iptr2);
+   return (XpmFileInvalid);
+   }
+   *s = (char) c;
+   }
slot = xpmHashSlot(hashtable, buf);
if (!*slot) {   /* no color matches */
XpmFree(iptr2);
@@ -519,8 +537,14 @@ do \
for (y = 0; y < height; y++) {
xpmNextString(data);
for (x = 0; x < width; x++, iptr++) {
-   for (a = 0, s = buf; a < cpp; a++, s++)
-   *s = xpmGetC(data); /* int assigned to char, not a 
problem here */
+   for (a = 0, s = buf; a < cpp; a++, s++) {
+   int c = xpmGetC(data);
+   if (c < 0) {
+   XpmFree(iptr2);
+   return (XpmFileInvalid);
+   }
+   *s = (char) c;
+   }
for (a = 0; a < ncolors; a++)
if (!strcmp(colorTable[a].string, buf))
break;
-- 
2.10.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[patch libICE] Fix use after free on subsequent calls

2016-12-06 Thread Matthieu Herrb
From: Tobias Stoeckmann 

The function IceAuthFileName is vulnerable to a use after free. The
flaw can be triggered by calling the function three times:

- First call succeeds and stores the path in buf, a dynamically
  allocated buffer with size bsize.
- Second call fails due to out of memory. It frees buf, but keeps
  the old size in bsize.
- Third call only checks if bsize is large enough. Then it uses
  buf without allocating it again -- the use after free happens.

In order to exploit this, an attacker must change environment variables
between each call, namely ICEAUTHORITY or HOME. It also takes subsequent
calls. Due to these limitations, I don't consider this to be of high
priority.
---
 src/authutil.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git src/authutil.c src/authutil.c
index 04c0791..ca0504a 100644
--- src/authutil.c
+++ src/authutil.c
@@ -114,8 +114,10 @@ IceAuthFileName (void)
if (buf)
free (buf);
buf = malloc (size);
-   if (!buf)
+   if (!buf) {
+   bsize = 0;
return (NULL);
+   }
bsize = size;
 }
 
-- 
2.10.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libXpm] Fix out out boundary read on unknown colors

2016-12-06 Thread Matthieu Herrb
From: Tobias Stoeckmann 

libXpm is vulnerable to an out of boundary read if an XPM file contains
a color with a symbolic name but without any default color value.

A caller must set XpmColorSymbols and a color with a NULL name in
the supplied XpmAttributes to XpmReadFileToImage (or other functions of
this type) in order to trigger this issue.
---
 src/create.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/create.c b/src/create.c
index d013da9..a750846 100644
--- a/src/create.c
+++ b/src/create.c
@@ -647,7 +647,8 @@ CreateColors(
while (def_index <= 5 && defaults[def_index] == NULL)
++def_index;
}
-   if (def_index >= 2 && defaults[def_index] != NULL &&
+   if (def_index >= 2 && def_index <= 5 &&
+   defaults[def_index] != NULL &&
!xpmstrcasecmp(symbol->value, defaults[def_index]))
break;
}
-- 
2.10.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] composite: Fix repaint of borders (v2)

2016-12-06 Thread Adam Jackson
When going from border width zero to a non-zero border width, the
Composite extension is informed via the ConfigNotify callback. The
call-chain looks like this: compConfigNotify -> compReallocPixmap ->
compSetPixmap -> TraverseTree -> compSetPixmapVisitWindow. However, at
this time, pWindow->borderWidth was not yet updated. Thus, HasBorder()
is false and the window border will not be repainted.

To fix this, thread the new bw through to the window visitor, and
inspect that rather than HasBorder(). For all the other callers the
border does not change size, so we can pass pWin->borderWidth instead.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98499
Signed-off-by: Adam Jackson 
---
 composite/compalloc.c  | 6 +++---
 composite/compint.h| 2 +-
 composite/compwindow.c | 9 ++---
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/composite/compalloc.c b/composite/compalloc.c
index e6a203f..05ffc7e 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -612,7 +612,7 @@ compAllocPixmap(WindowPtr pWin)
 else
 pWin->redirectDraw = RedirectDrawManual;
 
-compSetPixmap(pWin, pPixmap);
+compSetPixmap(pWin, pPixmap, bw);
 cw->oldx = COMP_ORIGIN_INVALID;
 cw->oldy = COMP_ORIGIN_INVALID;
 cw->damageRegistered = FALSE;
@@ -651,7 +651,7 @@ compSetParentPixmap(WindowPtr pWin)
 RegionCopy(>borderClip, >borderClip);
 pParentPixmap = (*pScreen->GetWindowPixmap) (pWin->parent);
 pWin->redirectDraw = RedirectDrawNone;
-compSetPixmap(pWin, pParentPixmap);
+compSetPixmap(pWin, pParentPixmap, pWin->borderWidth);
 }
 
 /*
@@ -682,7 +682,7 @@ compReallocPixmap(WindowPtr pWin, int draw_x, int draw_y,
 if (!pNew)
 return FALSE;
 cw->pOldPixmap = pOld;
-compSetPixmap(pWin, pNew);
+compSetPixmap(pWin, pNew, bw);
 }
 else {
 pNew = pOld;
diff --git a/composite/compint.h b/composite/compint.h
index 09241f2..f05c2d8 100644
--- a/composite/compint.h
+++ b/composite/compint.h
@@ -274,7 +274,7 @@ void
 #endif
 
 void
- compSetPixmap(WindowPtr pWin, PixmapPtr pPixmap);
+ compSetPixmap(WindowPtr pWin, PixmapPtr pPixmap, int bw);
 
 Bool
  compCheckRedirect(WindowPtr pWin);
diff --git a/composite/compwindow.c b/composite/compwindow.c
index 344138a..bcd230c 100644
--- a/composite/compwindow.c
+++ b/composite/compwindow.c
@@ -89,6 +89,7 @@ compCheckTree(ScreenPtr pScreen)
 typedef struct _compPixmapVisit {
 WindowPtr pWindow;
 PixmapPtr pPixmap;
+int bw;
 } CompPixmapVisitRec, *CompPixmapVisitPtr;
 
 static Bool
@@ -126,19 +127,20 @@ compSetPixmapVisitWindow(WindowPtr pWindow, void *data)
  */
 SetWinSize(pWindow);
 SetBorderSize(pWindow);
-if (HasBorder(pWindow))
+if (pVisit->bw)
 QueueWorkProc(compRepaintBorder, serverClient,
   (void *) (intptr_t) pWindow->drawable.id);
 return WT_WALKCHILDREN;
 }
 
 void
-compSetPixmap(WindowPtr pWindow, PixmapPtr pPixmap)
+compSetPixmap(WindowPtr pWindow, PixmapPtr pPixmap, int bw)
 {
 CompPixmapVisitRec visitRec;
 
 visitRec.pWindow = pWindow;
 visitRec.pPixmap = pPixmap;
+visitRec.bw = bw;
 TraverseTree(pWindow, compSetPixmapVisitWindow, (void *) );
 compCheckTree(pWindow->drawable.pScreen);
 }
@@ -463,7 +465,8 @@ compReparentWindow(WindowPtr pWin, WindowPtr pPriorParent)
  * Reset pixmap pointers as appropriate
  */
 if (pWin->parent && pWin->redirectDraw == RedirectDrawNone)
-compSetPixmap(pWin, (*pScreen->GetWindowPixmap) (pWin->parent));
+compSetPixmap(pWin, (*pScreen->GetWindowPixmap) (pWin->parent),
+  pWin->borderWidth);
 /*
  * Call down to next function
  */
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Why Xorg waits for long time(200ms+) to invoke VT_RELDISP?

2016-12-06 Thread Adam Jackson
On Thu, 2016-11-17 at 14:18 +0800, Yu Chen wrote:

> May I know why Xorg takes 200ms+ before acking with VT_RELDISP?

Because it's been asked to set the hardware back to text mode, which
requires reprogramming the GPU, which takes time.

200ms is more time than it probably _should_ take, but you haven't
specified (either in this email or in the bug you link to) what GPU
this is and which driver you're using, so I can't be any more specific
about what exactly is taking so much time and how it can be avoided
without that.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver PULL master] randr fixes + primary GPU fallback

2016-12-06 Thread Adam Jackson
On Tue, 2016-12-06 at 15:22 +0100, Hans de Goede wrote:
> Hi,
> 
> On Mon Dec 5 16:54:51 UTC 2016, Adam Jackson wrote:
>  > Not a fan of the autobind patch in terms of upstreaming, I feel like we
>  > really should be able to do better.
> 
> We've had years to do better

And? This is seat configuration. It's something the system should tell
us, not something we should guess at. That solves it both for all DEs
and for all display servers.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver v3] autobind GPUs to the screen

2016-12-06 Thread Hans de Goede
From: Dave Airlie 

This is a modified version of a patch we've been carry-ing in Fedora and
RHEL for years now. This patch automatically adds secondary GPUs to the
master as output sink / offload source making e.g. the use of
slave-outputs just work, with requiring the user to manually run
"xrandr --setprovideroutputsource" before he can hookup an external
monitor to his hybrid graphics laptop.

There is one problem with this patch, which is why it was not upstreamed
before. What to do when a secondary GPU gets detected really is a policy
decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
as such should be under control of the Desktop Environment.

Unconditionally adding autobinding support to the xserver will result
in races between the DE dealing with the hotplug of a secondary GPU
and the server itself dealing with it.

However we've waited for years for any Desktop Environments to actually
start doing some sort of autoconfiguration of secondary GPUs and there
is still not a single DE dealing with this, so I believe that it is
time to upstream this now.

To avoid potential future problems if any DEs get support for doing
secondary GPU configuration themselves, the new autobind functionality
is made optional. Since no DEs currently support doing this themselves it
is enabled by default. When DEs grow support for doing this themselves
they can disable the servers autobinding through the servers cmdline or a
xorg.conf snippet.

Signed-off-by: Dave Airlie 
[hdego...@redhat.com: Make configurable, fix with nvidia, submit upstream]
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Make the default enabled instead of installing a xorg.conf
 snippet which enables it unconditionally
Changes in v3:
-Handle GPUScreen autoconfig in randr/rrprovider.c, looking at
 rrScrPriv->provider, rather then in hw/xfree86/modes/xf86Crtc.c
 looking at xf86CrtcConfig->provider. This fixes the autoconfig not
 working with the nvidia binary driver
---
 hw/xfree86/common/xf86Config.c  | 19 +++
 hw/xfree86/common/xf86Globals.c |  2 ++
 hw/xfree86/common/xf86Init.c| 20 
 hw/xfree86/common/xf86Priv.h|  1 +
 hw/xfree86/common/xf86Privstr.h |  1 +
 hw/xfree86/common/xf86platformBus.c |  4 
 hw/xfree86/man/Xorg.man |  7 +++
 hw/xfree86/man/xorg.conf.man|  6 ++
 randr/randrstr.h|  3 +++
 randr/rrprovider.c  | 22 ++
 10 files changed, 85 insertions(+)

diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 21daf1a..df3ca50 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -719,6 +719,7 @@ typedef enum {
 FLAG_DRI2,
 FLAG_USE_SIGIO,
 FLAG_AUTO_ADD_GPU,
+FLAG_AUTO_BIND_GPU,
 FLAG_MAX_CLIENTS,
 FLAG_IGLX,
 } FlagValues;
@@ -778,6 +779,8 @@ static OptionInfoRec FlagOptions[] = {
  {0}, FALSE},
 {FLAG_AUTO_ADD_GPU, "AutoAddGPU", OPTV_BOOLEAN,
  {0}, FALSE},
+{FLAG_AUTO_BIND_GPU, "AutoBindGPU", OPTV_BOOLEAN,
+ {0}, FALSE},
 {FLAG_MAX_CLIENTS, "MaxClients", OPTV_INTEGER,
  {0}, FALSE },
 {FLAG_IGLX, "IndirectGLX", OPTV_BOOLEAN,
@@ -857,6 +860,22 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, 
XF86OptionPtr layoutopts)
 }
 xf86Msg(from, "%sutomatically adding GPU devices\n",
 xf86Info.autoAddGPU ? "A" : "Not a");
+
+if (xf86AutoBindGPUDisabled) {
+xf86Info.autoBindGPU = FALSE;
+from = X_CMDLINE;
+}
+else if (xf86IsOptionSet(FlagOptions, FLAG_AUTO_BIND_GPU)) {
+xf86GetOptValBool(FlagOptions, FLAG_AUTO_BIND_GPU,
+  );
+from = X_CONFIG;
+}
+else {
+from = X_DEFAULT;
+}
+xf86Msg(from, "%sutomatically binding GPU devices\n",
+xf86Info.autoBindGPU ? "A" : "Not a");
+
 /*
  * Set things up based on the config file information.  Some of these
  * settings may be overridden later when the command line options are
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index e962b75..0d1e31b 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -136,6 +136,7 @@ xf86InfoRec xf86Info = {
 #else
 .autoAddGPU = FALSE,
 #endif
+.autoBindGPU = TRUE,
 };
 
 const char *xf86ConfigFile = NULL;
@@ -197,6 +198,7 @@ Bool xf86FlipPixels = FALSE;
 Gamma xf86Gamma = { 0.0, 0.0, 0.0 };
 
 Bool xf86AllowMouseOpenFail = FALSE;
+Bool xf86AutoBindGPUDisabled = FALSE;
 
 #ifdef XF86VIDMODE
 Bool xf86VidModeDisabled = FALSE;
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index a544b65..b0cba3d 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -76,6 +76,7 @@
 #include "xf86DDC.h"
 #include "xf86Xinput.h"
 #include "xf86InPriv.h"
+#include "xf86Crtc.h"
 #include "picturestr.h"
 
 

Re: [xserver PULL master] randr fixes + primary GPU fallback

2016-12-06 Thread Hans de Goede

Hi,

On Mon Dec 5 16:54:51 UTC 2016, Adam Jackson wrote:
> Not a fan of the autobind patch in terms of upstreaming, I feel like we
> really should be able to do better.

We've had years to do better and carried this patch
in both Fedora and RHEL for years and nothing better
materialized, I think we're really doing (other)
downstream users a dis-service by keeping this patch
out of upstream. I can only hope that other distros
are including it themselves, otherwise a lot of
the effort spend on making prime setups work smoothly
is wasted, unless users can find the right magic
xrandr commands to make things work in google ...

Regards,

Hans


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel