[PATCH] libXinerama: Set number to 0 on error.

The documentation of XineramaQueryScreens states that number is always set to the amount of screens in the returned array, but if the communication with the X server fails, NULL is returned without modifying number. At least dwm relies on the fact that number is set to 0 on error, i.e. when NULL

Re: [PATCH] libXinerama: Set number to 0 on error.

On Mon, Jan 23, 2017 at 11:52:13AM -0500, Adam Jackson wrote: > Not that any caller has likely made this mistake, but you want an if > (number) before this, otherwise you turn a protocol error into a > segfault. If a caller supplies NULL, a segfault would always occur because the pointer is never

[PATCH] xinit: check for correct fork error code

Even though this code is only active on __sun machines, the fork return value should be checked for -1, not 1, to detect an error situation. --- xinit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xinit.c b/xinit.c index 1b04911..f826b7a 100644 --- a/xinit.c +++ b/xinit.c

Re: [PATCH libXrandr] Avoid out of boundary accesses on illegal responses

Hi Julien, On Sat, Jan 07, 2017 at 07:03:17PM +0100, Julien Cristau wrote: > It looks like we're leaking 'attr' on these error paths? confirmed. That is what I get for copying the error handling of the attr == NULL case... diff --git a/src/XrrCrtc.c b/src/XrrCrtc.c index 6665092..8316b78

[PATCH xserver] Fix OOB access in ProcRecordUnregisterClients

If a client sends a RecordUnregisterClients request with an nClients field larger than INT_MAX / 4, an integer overflow leads to an out of boundary access in RecordSanityCheckClientSpecifiers. An example line with libXtst would be: XRecordUnregisterClients(dpy, rc, clients, 0x4001); ---

[PATCH] dmx: Fix null pointer dereference

A null pointer dereference can occur in dmxSync, because TimerForce does not handle a null pointer. dmxSyncTimer is set to NULL a few lines above on a certain condition, which happened on my machine. The explicit NULL check allowed me to start Xdmx again without a segmentation fault. ---

Re: [PATCH] dmx: Fix null pointer dereference

On Sun, Mar 12, 2017 at 03:47:50PM +0100, walter harms wrote: > why not patch TimerForce() and solve the problem for once and any one ? I didn't do it because I am not sure about the implied consequences of simply accepting NULL. Maybe it's not meant to be used that way. But here's the

[PATCH] render: Fix out of boundary heap access

ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must be protected against an integer overflow during length check. This is already included in ProcRenderCreateLinearGradient since the fix for CVE-2008-2362. This can only be successfully exploited on a 32 bit system for an out

[PATCH libXaw] NULL pointer dereference in XawAsciiSinkInitialize

font setup: $ xmessage -b text Warning: Unable to load any usable ISO8859 font Segmentation fault $ _ Signed-off-by: Tobias Stoeckmann <tob...@stoeckmann.org> --- src/AsciiSink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/AsciiSink.c b/src/AsciiSink.c index d

[PATCH libXau] Avoid out of boundary read access

ed, a relative HOME path leads to trouble in general, the code should properly return "a/.Xauthority" nonetheless. Signed-off-by: Tobias Stoeckmann <tob...@stoeckmann.org> --- AuFileName.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AuFileName.

[PATCH font-util] ucs2any: Fix parser crash on 32 bit

urn NULL, e.g. on Linux/glibc systems. Such a result value is handled as an error and errno is evaluated and returned, even though there was no error: $ cat > source.bdf << "EOF" STARTFONT source CHARS 1 ENCODING 1 ENCODING 1073741823 EOF $ ucs2any source.bdf ucs2any: Success $ echo

[PATCH libICE] Always terminate strncpy results.

The function strncpy does not guarantee to append a terminating NUL character to the destination. This patch merges libSM's way of handling this issue into libICE. Signed-off-by: Tobias Stoeckmann --- src/connect.c| 66 +++- src/listen.c | 24

[PATCH app/xlsatoms 1/3] Support xcb_atom_t in range specification.

$ _ $ xlsatoms-new -range 0--1 xlsatoms-new: invalid range: 0--1 Signed-off-by: Tobias Stoeckmann --- xlsatoms.c | 51 +-- 1 file changed, 41 insertions(+), 10 deletions(-) diff --git a/xlsatoms.c b/xlsatoms.c index d3e0883..2bb5b47 100644

[PATCH app/xlsatoms 3/3] Always use chunks when retrieving atoms.

. Signed-off-by: Tobias Stoeckmann --- xlsatoms.c | 51 ++- 1 file changed, 14 insertions(+), 37 deletions(-) diff --git a/xlsatoms.c b/xlsatoms.c index 5bed0cc..a971901 100644 --- a/xlsatoms.c +++ b/xlsatoms.c @@ -234,7 +234,7 @@ do_range

[PATCH app/xlsatoms 2/3] Actually stop after an invalid atom.

. retrieves 100 atoms at a time. If one of them is invalid, the rest is still printed. With this adjustment, xlsatoms behaves as stated in manual page. Signed-off-by: Tobias Stoeckmann --- xlsatoms.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/xlsatoms.c b

[PATCH app/xlsatoms] Adjust man page to show default format.

The default format is %lu\t%s, not %ld\t%s, i.e. unsigned. Signed-off-by: Tobias Stoeckmann --- man/xlsatoms.man | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/xlsatoms.man b/man/xlsatoms.man index afa89bf..34d386e 100644 --- a/man/xlsatoms.man +++ b/man/xlsatoms.man

[PATCH app/xinit] Buffer overflow with many arguments.

Command line arguments are copied into clientargv and serverargv without verifying that enough space is available. A high amount of arguments can therefore trigger a buffer overflow like this: $ xinit $(seq 1 500) Signed-off-by: Tobias Stoeckmann --- xinit.c | 7 --- 1 file changed, 4

Re: [PATCH app/xinit] Buffer overflow with many arguments.

Command line arguments are copied into clientargv and serverargv without verifying that enough space is available. A high amount of arguments can therefore trigger a buffer overflow like this: $ xinit $(seq 1 500) Signed-off-by: Tobias Stoeckmann --- Integrated calculation as suggested