1. 27 Oct, 2015 1 commit
    • Martin Peres's avatar
      os: make sure the clientsWritable fd_set is initialized before use · 50c16716
      Martin Peres authored
      In WaitForSomething(), the fd_set clientsWritable may be used
      unitialized when the boolean AnyClientsWriteBlocked is set in the
      WakeupHandler(). This leads to a crash in FlushAllOutput() after
      x11proto's commit 2c94cdb453bc641246cc8b9a876da9799bee1ce7.
      
      The problem did not manifest before because both the XFD_SIZE and the
      maximum number of clients were set to 256. As the connectionTranslation
      table was initalized for the 256 clients to 0, the test on the index not
      being 0 was aborting before dereferencing the client #0.
      
      As of commit 2c94cdb453bc641246cc8b9a876da9799bee1ce7 in x11proto, the
      XFD_SIZE got bumped to 512. This lead the OutputPending fd_set to have
      any fd above 256 to be uninitialized which in turns lead to reading an
      index after the end of the ConnectionTranslation table. This index would
      then be used to find the client corresponding to the fd marked as
      pending writes and would also result to an out-of-bound access which
      would usually be the fatal one.
      
      Fix this by zeroing the clientsWritable fd_set at the beginning of
      WaitForSomething(). In this case, the bottom part of the loop, which
      would indirectly call FlushAllOutput, will not do any work but the next
      call to select will result in the execution of the right codepath. This
      is exactly what we want because we need to know the writable clients
      before handling them. In the end, it also makes sure that the fds above
      MaxClient are initialized, preventing the crash in FlushAllOutput().
      
      Thanks to everyone involved in tracking this one down!
      Reported-by: default avatarKarol Herbst <freedesktop@karolherbst.de>
      Reported-by: default avatarTobias Klausmann <tobias.klausmann@mni.thm.de>
      Signed-off-by: default avatarMartin Peres <martin.peres@linux.intel.com>
      Tested-by: default avatarTobias Klausmann <tobias.klausmann@mni.thm.de>
      Tested-by: default avatarMartin Peres <martin.peres@linux.intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91316
      Cc: Ilia Mirkin  <imirkin@alum.mit.edu>
      Cc: Olivier Fourdan <ofourdan@redhat.com
      Cc: Adam Jackson <ajax@redhat.com>
      Cc: Alan Coopersmith <alan.coopersmith@oracle.com
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      50c16716
  2. 19 Oct, 2015 3 commits
  3. 24 Sep, 2015 1 commit
  4. 21 Sep, 2015 5 commits
    • Keith Packard's avatar
      os/xdmcp: Just send XDMCP keepalive packets once every three minutes · db1089ea
      Keith Packard authored
      There was a complicated scheme to increase the time between keepalives
      from 3 minutes up to as much as 24 hours in an attempt to reduce
      network traffic from idle X terminals. X terminals receiving X
      traffic, or receiving user input would use the 3 minute value; X
      terminals without any network traffic would use a longer value.
      
      However, this was actually broken -- any activity in the X server,
      either client requests or user input, would end up resetting the
      keepalive timeout, so a user mashing on the keyboard would never
      discover that the XDMCP master had disappeared and have the session
      terminated, which was precisely the design goal of the XDMCP keepalive
      mechanism.
      
      Instead of attempting to fix this, accept the cost of a pair of XDMCP
      packets once every three minutes and just perform keepalives
      regularly.
      
      This will also make reworking the block and wakeup handler APIs to
      eliminate select masks easier.
      Reviewed-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      db1089ea
    • Keith Packard's avatar
      os/xdmcp: Remove dead 'restart' code · a3a40291
      Keith Packard authored
      The X server used to wait for the user to hit a key or move the mouse
      before restarting the session after a keepalive failure. This,
      presumably, was to avoid having the X server continuously spew XDMCP
      protocol on the network while the XDM server was dead.
      
      Switching into this state was removed from the server some time before
      XFree86 4.3.99.16, so the remaining bits of code have been dead for
      over a decade, and no-one ever noticed.
      Reviewed-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      a3a40291
    • Jon TURNEY's avatar
      mingw: Fix NO_LOCAL_CLIENT_CRED build · cdd1d581
      Jon TURNEY authored
      Commit 4b4b9086 "os: support new implicit local user access mode [CVE-2015-3164
      2/3]" carefully places the relevant code it adds under !NO_LOCAL_CLIENT_CRED,
      but unfortunately doesn't notice that NO_LOCAL_CLIENT_CRED is defined as a
      side-effect in the middle of GetLocalClientCreds(), so many of these checks
      precede its definition.
      
      Move the check if NO_LOCAL_CLIENT_CRED should be defined to configure.ac, so it
      always occurs before it's first use.
      
      v2:
      Move check to configure.ac
      
      v3:
      Use AC_CACHE_CHECK and name cache varaible appropriately
      
      [ajax: Massaged commit message]
      Signed-off-by: default avatarJon TURNEY <jon.turney@dronecode.org.uk>
      Reviewed-by: default avatarRay Strode <rstrode@redhat.com>
      cdd1d581
    • Daniel Drake's avatar
      Keep SIGALRM restart flag after Popen · 1f915e8b
      Daniel Drake authored
      Commit 94ab7455 added SA_RESTART to the SIGALRM handler.  However, the
      Popen code tears down and recreates the SIGALRM handler via OsSignal(),
      and this flag is dropped at this time.
      
      Clean the code to use just a single codepath for creating this signal
      handler, always applying SA_RESTART.
      
      [ajax: Fixed commit id]
      Reviewed-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      1f915e8b
    • Daniel Drake's avatar
      Allow system call restarts upon signal interruption · 94ab7455
      Daniel Drake authored
      The X server frequently deals with SIGIO and SIGALRM interruptions.
      If process execution is inside certain blocking system calls
      when these signals arrive, e.g. with the kernel blocked on
      a contended semaphore, the system calls will be interrupted.
      
      Some system calls are automatically restartable (the kernel re-executes
      them with the same parameters once the signal handler returns) but
      only if the signal handler allows it.
      
      Set SA_RESTART on the signal handlers to enable this convenient
      behaviour.
      Reviewed-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      94ab7455
  5. 24 Aug, 2015 1 commit
    • Olivier Fourdan's avatar
      configurable maximum number of clients · d206c240
      Olivier Fourdan authored
      Make the maximum number of clients user configurable, either from the command
      line or from xorg.conf
      
      This patch works by using the MAXCLIENTS (raised to 512) as the maximum
      allowed number of clients, but allowing the actual limit to be set by the
      user to a lower value (keeping the default of 256).
      
      There is a limit size of 29 bits to be used to store both the client ID and
      the X resources ID, so by reducing the number of clients allowed to connect to
      the X server, the user can increase the number of X resources per client or
      vice-versa.
      
      Parts of this patch are based on a similar patch from Adam Jackson
      <ajax@redhat.com>
      
      This now requires at least xproto 7.0.28
      Signed-off-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      d206c240
  6. 08 Jul, 2015 1 commit
  7. 26 May, 2015 2 commits
    • Vicente Olivert Riera's avatar
      backtrace.c: Fix word cast to a pointer · baa50f60
      Vicente Olivert Riera authored
      backtrace.c uses a word size provided by libunwind. In some
      architectures like MIPS, libunwind makes that word size 64-bit for all
      variants of the architecture.
      
      In the lines #90 and #98, backtrace.c tries to do a cast to a pointer,
      which fails in all MIPS variants with 32-bit pointers, like MIPS32 or
      MIPS64 n32, because it's trying to do a cast from a 64-bit wide variable
      to a 32-bit pointer:
      
      Making all in os
      make[2]: Entering directory
      `/home/test/test/1/output/build/xserver_xorg-server-1.15.1/os'
        CC     WaitFor.lo
        CC     access.lo
        CC     auth.lo
        CC     backtrace.lo
      backtrace.c: In function 'xorg_backtrace':
      backtrace.c:90:20: error: cast to pointer from integer of different size
      [-Werror=int-to-pointer-cast]
      	 if (dladdr((void *)(pip.start_ip + off), &dlinfo) &&
      dlinfo.dli_fname &&
      		    ^
      backtrace.c:98:13: error: cast to pointer from integer of different size
      [-Werror=int-to-pointer-cast]
      	     (void *)(pip.start_ip + off));
      	     ^
      cc1: some warnings being treated as errors
      make[2]: *** [backtrace.lo] Error 1
      make[2]: *** Waiting for unfinished jobs....
      
      Making the cast to a pointer-sized integer, and then to a pointer fixes
      the problem.
      
      Related:
        https://bugs.freedesktop.org/show_bug.cgi?id=79939Signed-off-by: default avatarVicente Olivert Riera <Vincent.Riera@imgtec.com>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      baa50f60
    • Ray Strode's avatar
      os: support new implicit local user access mode [CVE-2015-3164 2/3] · 4b4b9086
      Ray Strode authored
      If the X server is started without a '-auth' argument, then
      it gets started wide open to all local users on the system.
      
      This isn't a great default access model, but changing it in
      Xorg at this point would break backward compatibility.
      
      Xwayland, on the other hand is new, and much more targeted
      in scope.  It could, in theory, be changed to allow the much
      more secure default of a "user who started X server can connect
      clients to that server."
      
      This commit paves the way for that change, by adding a mechanism
      for DDXs to opt-in to that behavior.  They merely need to call
      
      LocalAccessScopeUser()
      
      in their init functions.
      
      A subsequent commit will add that call for Xwayland.
      Signed-off-by: default avatarRay Strode <rstrode@redhat.com>
      Reviewed-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      4b4b9086
  8. 22 Apr, 2015 3 commits
  9. 21 Apr, 2015 4 commits
  10. 16 Mar, 2015 2 commits
  11. 13 Mar, 2015 2 commits
  12. 11 Feb, 2015 1 commit
    • Alan Coopersmith's avatar
      Get rid of const warnings in XSERVER_INPUT_EVENT dtrace probe calls · 9e002dfc
      Alan Coopersmith authored
      Use typedefs to work around dtrace dropping const qualifiers from probe
      arguments when generating Xserver-dtrace.h.   Add new probes.h header to
      avoid having to replicate these typedefs in every file with dtrace probes.
      
      Gets rid of these warnings from gcc 4.8:
       getevents.c:1096:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' discards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1096:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1651:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1651:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1791:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1791:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1921:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1921:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
      Signed-off-by: default avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      9e002dfc
  13. 26 Jan, 2015 1 commit
  14. 02 Jan, 2015 1 commit
  15. 20 Dec, 2014 1 commit
  16. 09 Dec, 2014 3 commits
  17. 30 Nov, 2014 2 commits
  18. 12 Nov, 2014 1 commit
  19. 28 Oct, 2014 1 commit
  20. 27 Oct, 2014 1 commit
  21. 24 Oct, 2014 1 commit
  22. 22 Sep, 2014 1 commit
  23. 19 Sep, 2014 1 commit