qwo crashes with exit status 139. We confirmed the crash by
re-running it in a fresh debian unstable installation.

The attachment [1] contains a testcase (under ./crash) crashing the
program. It ensures that you can easily reproduce the bug. Additionally,
under ./crash_info/, we include more information about the crash such as
a core dump, the dmesg generated by the crash, and its output.

Regards,
The Mayhem Team (Alexandre Rebert, Thanassis Avgerinos, Sang Kil Cha, David Brumley, Manuel Egele)
Cylab, Carnegie Mellon University

[1] http://www.forallsecure.com/bug-reports/35376b58f5fdfebd2f764f5f77fb6568bca50313/full_report

I had a look at the crash.  This is the valgrind report:

./crash.sh: line 13: warning: command substitution: ignored null byte in input
==3461783== Memcheck, a memory error detector
==3461783== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3461783== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3461783== Command: ../../src/qwo --foregrou @_ _
==3461783==
==3461783== Invalid read of size 4
==3461783==    at 0x10CA08: convert_color (window.c:406)
==3461783==    by 0x10A677: main (main.c:247)
==3461783==  Address 0xe0 is not stack'd, malloc'd or (recently) free'd
==3461783==
==3461783==
==3461783== Process terminating with default action of signal 11 (SIGSEGV)
==3461783==  Access not within mapped region at address 0xE0
==3461783==    at 0x10CA08: convert_color (window.c:406)
==3461783==    by 0x10A677: main (main.c:247)
==3461783==  If you believe this happened as a result of a stack
==3461783==  overflow in your program's main thread (unlikely but
==3461783==  possible), you can try to increase the size of the
==3461783==  main thread stack using the --main-stacksize= flag.
==3461783==  The main thread stack size used in this run was 8388608.
==3461783==
==3461783== HEAP SUMMARY:
==3461783==     in use at exit: 120 bytes in 3 blocks
==3461783==   total heap usage: 3 allocs, 0 frees, 120 bytes allocated
==3461783==
==3461783== LEAK SUMMARY:
==3461783==    definitely lost: 0 bytes in 0 blocks
==3461783==    indirectly lost: 0 bytes in 0 blocks
==3461783==      possibly lost: 0 bytes in 0 blocks
==3461783==    still reachable: 120 bytes in 3 blocks
==3461783==         suppressed: 0 bytes in 0 blocks
==3461783== Rerun with --leak-check=full to see details of leaked memory
==3461783==
==3461783== For lists of detected and suppressed errors, rerun with: -s
==3461783== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

The problem seem to be that a X display lookup method is passed a NULL
pointer.  The following patch seem to avoid the crash in question:

--- qwo-0.5.orig/src/main.c
+++ qwo-0.5/src/main.c
@@ -232,6 +232,10 @@ int main(int argc, char **argv)

        display_name = XDisplayName(NULL);
        dpy = XOpenDisplay(display_name);
+        if (!dpy) {
+            printf("error: Unable to find working X display\n");
+            exit(1);
+        }

        while ((options = getopt_long(argc, argv, "c:g:f:b:d:hv", long_options,
                                        &option_index)) != -1)


I do not quite understand why dpy is NULL here, but perhaps it can be
a starting point for someone who understand the code a bit more?