1. 27 Jul, 2021 1 commit
  2. 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
  3. 15 Jun, 2021 1 commit
  4. 12 Jun, 2021 1 commit
  5. 05 Jun, 2021 1 commit
  6. 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
  7. 30 May, 2021 1 commit
  8. 22 May, 2021 1 commit
  9. 18 May, 2021 2 commits
  10. 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
  11. 03 May, 2021 1 commit
  12. 12 Jan, 2021 2 commits
  13. 28 Nov, 2020 3 commits
  14. 27 Nov, 2020 5 commits
  15. 25 Nov, 2020 1 commit
  16. 19 Nov, 2020 1 commit
  17. 18 Nov, 2020 3 commits
  18. 17 Nov, 2020 1 commit
  19. 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_for_event is called (for instance from another poll_for_response);
      - event with sequence N is retrieved;
      - the N sequence is widen, however, as the "new" number computed from
        last_request_read is less than N the number is widened to N + 2^32
        (assuming last_request_read is still contained in 32 bit);
      - poll_for_event enters the nested if statement as req is NULL;
      - we compare the widen N (which now does not fit into 32 bit) with
        request (which fits into 32 bit) hitting the throw_thread_fail_assert.
      
      To avoid the race condition and to avoid the sequence to go back
      I check again for new events after getting the response and
      return this last event if present saving the reply to return it
      later.
      
      To test the race and the fix it's helpful to add a delay (I used a
      "usleep(5000)") before calling xcb_poll_for_reply64.
      
      Original patch written by Frediano Ziglio, see
      xorg/lib/libx11!34
      
      Reworked primarily for readability by Peter Hutterer, see
      xorg/lib/libx11!53
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      dbb55e1a
  20. 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. That function
      does everything that LockDisplay does *except* call those final two
      functions which may end up receiving an error.
      
      However, that doesn't protect the system from applications which call
      some legal Xlib function from within their error handler. Any Xlib
      function which cannot generate protocol or wait for events is valid,
      including many which invoke LockDisplay.
      
      What we need to do is make LockDisplay skip these two function calls
      precisely when it is called from within the _XError context for the
      same display.
      
      This patch accomplishes this by creating a list of threads in the
      display which are in _XError, and then having LockDisplay check the
      current thread against those list elements.
      Inspired-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Tested-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      Reviewed-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      30ccef3a
  21. 13 Nov, 2020 3 commits
  22. 09 Nov, 2020 4 commits
  23. 08 Nov, 2020 2 commits