1. 16 Jun, 2021 1 commit
    • Alexander Richardson's avatar
      Avoid undefined behaviour after realloc() · d01d2337
      Alexander Richardson authored
      Adding the offset between the realloc result and the old allocation to
      update pointers into the new allocation is undefined behaviour: the
      old pointers are no longer valid after realloc() according to the C
      standard. While this works on almost all architectures and compilers,
      it causes  problems on architectures that track pointer bounds (e.g.
      CHERI or Arm's Morello): the value_list pointers will still have the
      bounds of the previous allocation and therefore any dereference will
      result in a run-time trap.
      
      I found this due to a crash (dereferencing an invalid capability) while
      trying to run `xev` over SSH on a CHERI-RISC-V system. With these two
      realloc changes, and xorg/proto/xorgproto!41
      
      
      I am able to succesfully run `xev` compiled for CHERI-RISC-V.
      Signed-off-by: Alexander Richardson's avatarAlex Richardson <Alexander.Richardson@cl.cam.ac.uk>
      d01d2337
  2. 15 Jun, 2021 1 commit
  3. 12 Jun, 2021 1 commit
  4. 05 Jun, 2021 1 commit
  5. 31 May, 2021 1 commit
    • Tobias Stoeckmann's avatar
      Protect against overly long strings · 51b73ac0
      Tobias Stoeckmann authored
      
      
      Checking against upper limit of USHRT_MAX must happen before truncating
      size_t to int. On 64 bit systems with strings larger than 2 GB this
      could otherwise lead to negative ints or ints smaller than USHRT_MAX.
      
      In XParseColor this could lead to out of boundary access with strings
      starting with a # (color sequence). A modulo 12 operation is performed
      to validate the string length, but with an overflown length, the for
      loop would eventually read behind terminating '\0' character.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
      51b73ac0
  6. 30 May, 2021 1 commit
  7. 22 May, 2021 1 commit
  8. 18 May, 2021 2 commits
  9. 09 May, 2021 1 commit
    • Gaurav Ujjwal's avatar
      Fix out-of-bound access in KeySymToUcs4() · 838ea5a5
      Gaurav Ujjwal authored
      
      
      Array `keysym_to_unicode_590_5fe` is only valid for range  [0x590, 0x5fe] but current lower-bound is checked against 0x589.
      
      So invalid values from 0x58a to 0x58f are being allowed by current check.
      
      If any of these invalid value is passed as `keysym`,    `keysym - 0x590` would underflow.
      Signed-off-by: Gaurav Ujjwal's avatarGaurav Ujjwal <gujjwal00@gmail.com>
      838ea5a5
  10. 03 May, 2021 1 commit
  11. 12 Jan, 2021 2 commits
  12. 28 Nov, 2020 3 commits
  13. 27 Nov, 2020 5 commits
  14. 25 Nov, 2020 1 commit
  15. 19 Nov, 2020 1 commit
  16. 18 Nov, 2020 3 commits
  17. 17 Nov, 2020 1 commit
  18. 16 Nov, 2020 2 commits
    • Peter Hutterer's avatar
      gitlab CI: add a basic build test · 960e2e0c
      Peter Hutterer authored
      
      
      Using Arch as base distribution here because we can expect our dependencies to
      be up-to-date. We rely on the Arch for our dependencies rather than building
      those from git (notably: xorg-macros, xtrans and libxcb).
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      960e2e0c
    • Frediano Ziglio's avatar
      Fix poll_for_response race condition · dbb55e1a
      Frediano Ziglio authored
      In poll_for_response is it possible that event replies are skipped
      and a more up to date message reply is returned.
      This will cause next poll_for_event call to fail aborting the program.
      
      This was proved using some slow ssh tunnel or using some program
      to slow down server replies (I used a combination of xtrace and strace).
      
      How the race happens:
      - program enters into poll_for_response;
      - poll_for_event is called but the server didn't still send the reply;
      - pending_requests is not NULL because we send a request (see call
        to  append_pending_request in _XSend);
      - xcb_poll_for_reply64 is called from poll_for_response;
      - xcb_poll_for_reply64 will read from server, at this point
        server reply with an event (say sequence N) and the reply to our
        last request (say sequence N+1);
      - xcb_poll_for_reply64 returns the reply for the request we asked;
      - last_request_read is set to N+1 sequence in poll_for_response;
      - poll_for_response returns the response to the request;
      - poll...
      dbb55e1a
  19. 15 Nov, 2020 1 commit
    • Keith Packard's avatar
      Avoid recursing through _XError due to sequence adjustment · 30ccef3a
      Keith Packard authored
      This patch is based on research done by Dmitry Osipenko to uncover the
      cause of a large class of Xlib lockups.
      
      _XError must unlock and re-lock the display around the call to the
      user error handler function. When re-locking the display, two
      functions are called to ensure that the display is ready to generate a request:
      
          _XIDHandler(dpy);
          _XSeqSyncFunction(dpy);
      
      The first ensures that there is at least one XID available to use
      (possibly calling _xcb_generate_id to do so). The second makes sure a
      reply is received at least every 65535 requests to keep sequence
      numbers in sync (possibly generating a GetInputFocus request and
      synchronously awaiting the reply).
      
      If the second of these does generate a GetInputFocus request and wait
      for the reply, then a pending error will cause recursion into _XError,
      which deadlocks the display.
      
      One seemingly easy fix is to have _XError avoid those calls by
      invoking InternalLockDisplay instead of LockDisplay....
      30ccef3a
  20. 13 Nov, 2020 3 commits
  21. 09 Nov, 2020 4 commits
  22. 08 Nov, 2020 2 commits
  23. 05 Nov, 2020 1 commit