Skip to content
Snippets Groups Projects
  1. Dec 13, 2023
    • Peter Hutterer's avatar
      Bump version to 23.2.3 · 7439e9c6
      Peter Hutterer authored
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Xi: allocate enough XkbActions for our buttons · 19e9f199
      Peter Hutterer authored
      button->xkb_acts is supposed to be an array sufficiently large for all
      our buttons, not just a single XkbActions struct. Allocating
      insufficient memory here means when we memcpy() later in
      XkbSetDeviceInfo we write into memory that wasn't ours to begin with,
      leading to the usual security ooopsiedaisies.
      
      CVE-2023-6377, ZDI-CAN-22412, ZDI-CAN-22413
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit 0c1a93d3)
      19e9f199
    • Peter Hutterer's avatar
      randr: avoid integer truncation in length check of ProcRRChange*Property · aaf854fb
      Peter Hutterer authored
      Affected are ProcRRChangeProviderProperty and ProcRRChangeOutputProperty.
      See also 8f454b79 where this same bug was fixed for the core
      protocol and XI.
      
      This fixes an OOB read and the resulting information disclosure.
      
      Length calculation for the request was clipped to a 32-bit integer. With
      the correct stuff->nUnits value the expected request size was
      truncated, passing the REQUEST_FIXED_SIZE check.
      
      The server then proceeded with reading at least stuff->num_items bytes
      (depending on stuff->format) from the request and stuffing whatever it
      finds into the property. In the process it would also allocate at least
      stuff->nUnits bytes, i.e. 4GB.
      
      CVE-2023-6478, ZDI-CAN-22561
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit 14f48001)
      aaf854fb
  2. Dec 04, 2023
    • Olivier Fourdan's avatar
      xwayland: Use the right nameLength by default · eea4c753
      Olivier Fourdan authored
      
      When creating the output with the default "XWAYLAND<n>" name, we use
      the MAX_OUTPUT_NAME value to allocate a lot more memory than necessary
      to accommodate for future output names once they get updated, but by
      doing so, we also send XRandR way too much (zeroed) data since the
      "nameLength" value is (purposely) set too big.
      
      So, instead, let's just update the name after creating the RR output,
      this way we set both the name and nameLength to their correct values
      while keeping the initial large allocation.
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Fixes: 3c07a01c - xwayland: Use xdg-output name for XRandR
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      (cherry picked from commit 83453fb5)
      eea4c753
    • Olivier Fourdan's avatar
      xwayland: Update output nameLength · a07ce75d
      Olivier Fourdan authored
      
      At creation, Xwayland uses a generic output name ("XWAYLAND0", etc.) for
      the XRandR outputs, and later, once the name is known from the Wayland
      protocols, updates the output names using the actual names from the
      Wayland compositor.
      
      However, when doing so, it simply updates the string, the "nameLength"
      isn't updated, so the name passed to the clients might either end up
      being truncated or contain portions of the previous (initial) output
      name.
      
      Note, this is using a fixed size buffer initialized with zeros, so this
      cannot leak any data other than the previous output name, so this is
      mainly a cosmetic issue.
      
      Update the output's "nameLength" when updating the output name.
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Fixes: 3c07a01c - xwayland: Use xdg-output name for XRandR
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      (cherry picked from commit 0e314afe)
      a07ce75d
  3. Nov 29, 2023
  4. Oct 25, 2023
    • Peter Hutterer's avatar
      Bump version to 23.2.2 · e4487cae
      Peter Hutterer authored
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Xi/randr: fix handling of PropModeAppend/Prepend · 1e847845
      Peter Hutterer authored
      
      The handling of appending/prepending properties was incorrect, with at
      least two bugs: the property length was set to the length of the new
      part only, i.e. appending or prepending N elements to a property with P
      existing elements always resulted in the property having N elements
      instead of N + P.
      
      Second, when pre-pending a value to a property, the offset for the old
      values was incorrect, leaving the new property with potentially
      uninitalized values and/or resulting in OOB memory writes.
      For example, prepending a 3 element value to a 5 element property would
      result in this 8 value array:
        [N, N, N, ?, ?, P, P, P ] P, P
                                  ^OOB write
      
      The XI2 code is a copy/paste of the RandR code, so the bug exists in
      both.
      
      CVE-2023-5367, ZDI-CAN-22153
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 541ab2ec)
      1e847845
  5. Oct 24, 2023
  6. Oct 12, 2023
    • Olivier Fourdan's avatar
      xwayland: Cancel the EI disconnect timer when freed · 4f8a851b
      Olivier Fourdan authored
      
      Xwayland maintains a connection to EI up for 10 minutes after an X11
      client has vanished, to avoid going through the connection phase every
      time a short lived X11 client comes and goes.
      
      However, if the EI client gets freed (through some other event, e.g. the
      user decides to terminate the EI session), Xwayland would still keep the
      callback alive and end up trying to free an already freed EI client:
      
       Invalid read of size 4
          at 0x4C5E6F9: object_unref (util-object.h:89)
          by 0x4C5E6F9: ei_unref (libei.c:77)
          by 0x429525: free_ei (xwayland-xtest.c:224)
          by 0x429A6E: disconnect_timer_cb (xwayland-xtest.c:404)
          by 0x5E63FF: DoTimer (WaitFor.c:276)
          by 0x5E6463: DoTimers (WaitFor.c:290)
          by 0x5E6164: check_timers (WaitFor.c:133)
          by 0x5E61E9: WaitForSomething (WaitFor.c:195)
          by 0x4AD50E: Dispatch (dispatch.c:487)
          by 0x4BBA0B: dix_main (main.c:272)
          by 0x43615D: main (stubmain.c:34)
        Address 0x15cc6ee8 is 8 bytes inside a block of size 240 free'd
          at 0x48452AC: free (vg_replace_malloc.c:974)
          by 0x4C5E729: object_destroy (util-object.h:73)
          by 0x4C5E729: object_unref (util-object.h:91)
          by 0x4C5E729: ei_unref (libei.c:77)
          by 0x429525: free_ei (xwayland-xtest.c:224)
          by 0x42A946: xwl_handle_ei_event (xwayland-xtest.c:804)
          by 0x5EA977: HandleNotifyFd (connection.c:809)
          by 0x5EE8E3: ospoll_wait (ospoll.c:657)
          by 0x5E624D: WaitForSomething (WaitFor.c:208)
          by 0x4AD50E: Dispatch (dispatch.c:487)
          by 0x4BBA0B: dix_main (main.c:272)
          by 0x43615D: main (stubmain.c:34)
        Block was alloc'd at
          at 0x484782C: calloc (vg_replace_malloc.c:1554)
          by 0x4C5E777: ei_create (libei.c:73)
          by 0x4C5E777: ei_create_context (libei.c:97)
          by 0x42994B: setup_ei (xwayland-xtest.c:366)
          by 0x42A383: xwayland_xtest_send_events (xwayland-xtest.c:658)
          by 0x54ED4C: ProcXTestFakeInput (xtest.c:441)
          by 0x54EE56: ProcXTestDispatch (xtest.c:475)
          by 0x4AD6E6: Dispatch (dispatch.c:546)
          by 0x4BBA0B: dix_main (main.c:272)
          by 0x43615D: main (stubmain.c:34)
      
      To avoid that issue, make sure to cancel the timer as soon as a EI
      client is freed.
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      See-also: https://bugzilla.redhat.com/2243076
      (cherry picked from commit 9617de73)
      4f8a851b
    • JeffyChen's avatar
      glamor: xv: Fix invalid accessing of plane attributes for NV12 · cc79b2a8
      JeffyChen authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      NV12 only has 2 planes.
      
      Signed-off-by: JeffyChen's avatarJeffy Chen <jeffy.chen@rock-chips.com>
      (cherry picked from commit 0076671e)
      cc79b2a8
    • Olivier Fourdan's avatar
      xwayland: Give up on EI on setup failure · 07c18c90
      Olivier Fourdan authored
      
      If we fail to setup EI, give up on using EI for XTEST and restore the
      default XTEST handlers.
      
      This happens when neither the portal nor the socket backends are usable.
      
      This does not affect the portal operation though, if the user choose not
      to allow a particular client, Xwayland would continue to use EI.
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarJoshua Ashton <joshua@froggi.es>
      (cherry picked from commit 6b56ae68)
      07c18c90
    • Olivier Fourdan's avatar
      xwayland: Add an option to enable EI portal support · 10353a01
      Olivier Fourdan authored
      
      With EI support wired to XTEST, and oeffis being enabled unconditionally
      means that Xwayland will always go through the XDG portal for XTEST when
      supported.
      
      While this the intended behavior for the general use case of Xwayland
      running rootless on a desktop compositor, that breaks when Xwayland is
      running on a nested compositor, because the portal is for the entire
      session and not limited to the nested Wayland compositor.
      
      Xwayland itself, as a regular Wayland client, has no way to tell that it
      is running on a nested compositor.
      
      So to keep backward compatibility with existing (and also common) use
      cases such as nested compositors, best is to disable support for the XDG
      portal by default, and add a new command line option "-enable-ei-portal"
      for the Wayland compositors (who spawn Xwayland rootless) to explicitly
      enable support for the input emulation XDG portal in Xwayland.
      
      A Wayland compositor running nested should not use that command line
      option with Xwayland.
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarJoshua Ashton <joshua@froggi.es>
      Fixes: a1333342 - xwayland: Add XTEST support using EIS
      Closes: xorg/xserver#1586
      See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
      (cherry picked from commit cfcbb075)
      10353a01
    • José Expósito's avatar
      xwayland/glamor/gbm: Set GBM_BO_USE_LINEAR if only LINEAR modifier is supported · 4f8e209d
      José Expósito authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Some drivers might not support explicit format modifiers. On these
      drivers `gbm_bo_create_with_modifiers()` will fail and the
      `gbm_bo_create()` code path will be used instead.
      
      In this case, if the LINEAR modifier is advertised (and the INVALID
      modifier is not) add the `GBM_BO_USE_LINEAR` flag.
      
      Closes: xorg/xserver#1438
      
      
      Reviewed-by: default avatarMichel Dänzer <mdaenzer@redhat.com>
      Signed-off-by: default avatarJosé Expósito's avatarJosé Expósito <jexposit@redhat.com>
      (cherry picked from commit 287638db)
      4f8e209d
    • Michel Dänzer's avatar
      xwayland/present: Handle NULL window_priv in xwl_present_cleanup · c9a842e6
      Michel Dänzer authored and Olivier Fourdan's avatar Olivier Fourdan committed
      This can happen if the window has never completed a Present operation.
      
      Fixes: 42301760 ("xwayland/present: Embed present_vblank_rec in xwl_present_event")
      (cherry picked from commit 32c5b2c0)
      c9a842e6
    • Konstantin's avatar
      glamor: fixes GL_INVALID_ENUM errors on ES if there is no quads · 2bd43be9
      Konstantin authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      If there is no quads to draw, then we have a possibility to call
      glDrawElements with type as zero, which will generate
      GL_INVALID_ENUM error. While this error is harmless, it is annoying.
      
      Signed-off-by: default avatarKonstantin <ria.freelander@gmail.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      (cherry picked from commit baaddf47)
      2bd43be9
  7. Sep 20, 2023
  8. Sep 19, 2023
  9. Aug 16, 2023
  10. Aug 11, 2023
    • Kenny Levinsen's avatar
      xwayland: Commit after acknowledging configure · 67b2d80d
      Kenny Levinsen authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      When handling libdecor configure, we first update our xwl output and
      screen if dimensions differ from the current xwl_screen, and then commit
      a new libdecor frame which acknowledges the xdg_surface.configure event.
      
      If the initial configure events contains non-zero dimensions, we will
      update the xwl output before acknowledging the initial configure. As we
      attach a buffer and commit the surface when updating the output, this
      leads to a protocol error.
      
      Instead, move the surface commit till the end of the configure handler
      so it always happens after the ack.
      
      Signed-off-by: default avatarKenny Levinsen <kl@kl.wtf>
      (cherry picked from commit 295fb716)
      67b2d80d
  11. Aug 02, 2023
  12. Jul 27, 2023
Loading