1. 08 Jun, 2019 2 commits
    • Jon Turney's avatar
      Use EXEEXT_FOR_BUILD for makekeys · 6886d9ba
      Jon Turney authored
      Use EXEXT_FOR_BUILD, to fix cross-compiling where EXEEXT differs from
      EXEEXT_FOR_BUILD, such as when building for Windows from unix.
      (Note: As written, this assumes EXEEXT_FOR_BUILD is always empty when
      cross-compiling.  There could be some elaborate autodetection for
      EXEXT_FOR_BUILD, but for the moment, if you are cross-compiling from
      Windows to Unix, you'll need to set EXEEXT_FOR_BUILD explicity...)
    • Jon Turney's avatar
      Remove makekeys dependency on X headers · a121b7b0
      Jon Turney authored
      This is the patch from https://bugs.freedesktop.org/show_bug.cgi?id=6669
      by Pierre Ossman, reworked for master.
      Avoid using LIBS (which are for host, but we don't need) and rewrite
      makekeys slightly to avoid needing to include any X headers, which
      avoids potentially having -I with host paths in CFLAGS, which can cause
      standard headers e.g. stdio.h for the host to also be used, which can
      break things...
  2. 14 May, 2019 1 commit
  3. 30 Apr, 2019 1 commit
  4. 23 Feb, 2019 2 commits
  5. 16 Jan, 2019 2 commits
  6. 01 Jan, 2019 2 commits
    • Alan Coopersmith's avatar
      Fix implicit conversion warnings in _XlcCreateDefaultCharSet · 30656fd6
      Alan Coopersmith authored
      lcCharSet.c:187:50: warning: implicit conversion changes signedness:
            'int' to 'unsigned long' [-Wsign-conversion]
          tmp = Xmalloc(name_len + 1 + ct_sequence_len + 1);
      ../../include/X11/Xlibint.h:453:32: note: expanded from macro 'Xmalloc'
                             ~~~~~~  ^~~~
      lcCharSet.c:192:31: warning: implicit conversion changes signedness:
            'int' to 'unsigned long' [-Wsign-conversion]
          memcpy(tmp, name, name_len+1);
          ~~~~~~            ~~~~~~~~^~
      lcCharSet.c:216:45: warning: implicit conversion changes signedness:
            'int' to 'unsigned long' [-Wsign-conversion]
          memcpy(tmp, ct_sequence, ct_sequence_len+1);
          ~~~~~~                   ~~~~~~~~~~~~~~~^~
      lcCharSet.c:183:16: warning: implicit conversion loses integer precision:
            'unsigned long' to 'int' [-Wshorten-64-to-32]
          name_len = strlen(name);
                   ~ ^~~~~~~~~~~~
      lcCharSet.c:184:23: warning: implicit conversion loses integer precision:
            'unsigned long' to 'int' [-Wshorten-64-to-32]
          ct_sequence_len = strlen(ct_sequence);
                          ~ ^~~~~~~~~~~~~~~~~~~
      lcCharSet.c:198:37: warning: implicit conversion loses integer precision:
           'long' to 'unsigned int' [-Wshorten-64-to-32]
              unsigned int length = colon - charset->name;
                           ~~~~~~   ~~~~~~^~~~~~~~~~~~~~~
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
    • Alan Coopersmith's avatar
      Remove no-longer-used name variable in _XGetAtomName · 2e630090
      Alan Coopersmith authored
      Fixes gcc warning:
      GetAtomNm.c: In function ‘_XGetAtomName’:
      GetAtomNm.c:39:11: warning: unused variable ‘name’ [-Wunused-variable]
           char *name;
      Introduced by commit 336c1e7aSigned-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
  7. 29 Dec, 2018 1 commit
  8. 08 Dec, 2018 8 commits
  9. 28 Sep, 2018 1 commit
  10. 25 Sep, 2018 1 commit
  11. 22 Sep, 2018 1 commit
  12. 21 Aug, 2018 3 commits
    • Tobias Stoeckmann's avatar
      Fixed crash on invalid reply (CVE-2018-14598). · e8372276
      Tobias Stoeckmann authored
      If the server sends a reply in which even the first string would
      overflow the transmitted bytes, list[0] (or flist[0]) will be set to
      NULL and a count of 0 is returned.
      If the resulting list is freed with XFreeExtensionList or
      XFreeFontPath later on, the first Xfree call:
          Xfree (list[0]-1)
       turns into
          Xfree (NULL-1)
      which will most likely trigger a segmentation fault.
      I have modified the code to return NULL if the first string would
      overflow, thus protecting the freeing functions later on.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
    • Tobias Stoeckmann's avatar
      Fixed out of boundary write (CVE-2018-14600). · dbf72805
      Tobias Stoeckmann authored
      The length value is interpreted as signed char on many systems
      (depending on default signedness of char), which can lead to an out of
      boundary write up to 128 bytes in front of the allocated storage, but
      limited to NUL byte(s).
      Casting the length value to unsigned char fixes the problem and allows
      string values with up to 255 characters.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
    • Tobias Stoeckmann's avatar
      Fixed off-by-one writes (CVE-2018-14599). · b469da14
      Tobias Stoeckmann authored
      The functions XGetFontPath, XListExtensions, and XListFonts are
      vulnerable to an off-by-one override on malicious server responses.
      The server replies consist of chunks consisting of a length byte
      followed by actual string, which is not NUL-terminated.
      While parsing the response, the length byte is overridden with '\0',
      thus the memory area can be used as storage of C strings later on. To
      be able to NUL-terminate the last string, the buffer is reserved with
      an additional byte of space.
      For a boundary check, the variable chend (end of ch) was introduced,
      pointing at the end of the buffer which ch initially points to.
      Unfortunately there is a difference in handling "the end of ch".
      While chend points at the first byte that must not be written to,
      the for-loop uses chend as the last byte that can be written to.
      Therefore, an off-by-one can occur.
      I have refactored the code so chend actually points to the last byte
      that can be written to without an out of boundary access. As it is not
      possible to achieve "ch + length < chend" and "ch + length + 1 > chend"
      with the corrected chend meaning, I removed the inner if-check.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
  13. 17 Jul, 2018 1 commit
  14. 14 May, 2018 1 commit
  15. 05 May, 2018 1 commit
  16. 30 Mar, 2018 1 commit
  17. 24 Mar, 2018 1 commit
  18. 07 Mar, 2018 1 commit
  19. 03 Sep, 2017 1 commit
  20. 20 Aug, 2017 4 commits
  21. 14 Aug, 2017 4 commits