Skip to content
Snippets Groups Projects
  1. Dec 13, 2023
    • Peter Hutterer's avatar
      xserver 21.1.10 · 15e24097
      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 · a7bda308
      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)
      a7bda308
    • Peter Hutterer's avatar
      randr: avoid integer truncation in length check of ProcRRChange*Property · 58e83c68
      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)
      58e83c68
  2. Oct 25, 2023
    • nerdopolis's avatar
      xephyr: Don't check for SeatId anymore · c1ad8df2
      nerdopolis authored and Matt Turner's avatar Matt Turner committed
      After a change for the xserver to automatically determine the seat
      based on the XDG_SEAT variable, xephyr stopped working. This was
      because of an old feature where xephyr used to handle evdev
      directly. This was dropped some time ago, and now this check is
      not needed
      
      (cherry picked from commit 4c03b67d)
      c1ad8df2
    • Peter Hutterer's avatar
      xserver 21.1.9 · 6197bea0
      Peter Hutterer authored
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      mi: reset the PointerWindows reference on screen switch · 3e290b3c
      Peter Hutterer authored
      
      PointerWindows[] keeps a reference to the last window our sprite
      entered - changes are usually handled by CheckMotion().
      
      If we switch between screens via XWarpPointer our
      dev->spriteInfo->sprite->win is set to the new screen's root window.
      If there's another window at the cursor location CheckMotion() will
      trigger the right enter/leave events later. If there is not, it skips
      that process and we never trigger LeaveWindow() - PointerWindows[] for
      the device still refers to the previous window.
      
      If that window is destroyed we have a dangling reference that will
      eventually cause a use-after-free bug when checking the window hierarchy
      later.
      
      To trigger this, we require:
      - two protocol screens
      - XWarpPointer to the other screen's root window
      - XDestroyWindow before entering any other window
      
      This is a niche bug so we hack around it by making sure we reset the
      PointerWindows[] entry so we cannot have a dangling pointer. This
      doesn't handle Enter/Leave events correctly but the previous code didn't
      either.
      
      CVE-2023-5380, ZDI-CAN-21608
      
      This vulnerability was discovered by:
      Sri working with Trend Micro Zero Day Initiative
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      (cherry picked from commit 564ccf2c)
      3e290b3c
    • Peter Hutterer's avatar
      Xi/randr: fix handling of PropModeAppend/Prepend · f2922f6f
      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)
      f2922f6f
  3. Oct 24, 2023
  4. Apr 24, 2023
  5. Mar 29, 2023
  6. Feb 07, 2023
  7. Jan 26, 2023
  8. Jan 17, 2023
  9. Jan 15, 2023
  10. Jan 11, 2023
    • Olivier Fourdan's avatar
      dix: Fix overzealous caching of ResourceClientBits() · c8ef9e38
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Commit c7311654 cached the value of ResourceClientBits(), but that value
      depends on the `MaxClients` value set either from the command line or
      from the configuration file.
      
      For the latter, a call to ResourceClientBits() is issued before the
      configuration file is read, meaning that the cached value is from the
      default, not from the maximum number of clients set in the configuration
      file.
      
      That obviously causes all sort of issues, including memory corruption
      and crashes of the Xserver when reaching the default limit value.
      
      To avoid that issue, also keep the LimitClient value, and recompute the
      ilog2() value if that changes, as on startup when the value is set from
      the the xorg.conf ServerFlags section.
      
      v2: Drop the `cache == 0` test
          Rename cache vars
      
      Fixes: c7311654 - dix: cache ResourceClientBits() value
      Closes: #1310
      
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      (cherry picked from commit 2efa6d65)
      c8ef9e38
  11. Dec 21, 2022
  12. Dec 19, 2022
  13. Dec 14, 2022
    • Peter Hutterer's avatar
      xkb: fix some possible memleaks in XkbGetKbdByName · 69ab3bca
      Peter Hutterer authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      GetComponentByName returns an allocated string, so let's free that if we
      fail somewhere.
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 18f91b95)
      69ab3bca
    • Peter Hutterer's avatar
      xkb: proof GetCountedString against request length attacks · 5dbb2b52
      Peter Hutterer authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      GetCountedString did a check for the whole string to be within the
      request buffer but not for the initial 2 bytes that contain the length
      field. A swapped client could send a malformed request to trigger a
      swaps() on those bytes, writing into random memory.
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 11beef0b)
      5dbb2b52
    • Jeremy Huddleston Sequoia's avatar
    • John D Pell's avatar
    • Peter Hutterer's avatar
      xserver 21.1.5 · f292fbfa
      Peter Hutterer authored
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      xkb: reset the radio_groups pointer to NULL after freeing it · e860bbce
      Peter Hutterer authored
      
      Unlike other elements of the keymap, this pointer was freed but not
      reset. On a subsequent XkbGetKbdByName request, the server may access
      already freed memory.
      
      CVE-2022-4283, ZDI-CAN-19530
      
      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>
      Acked-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit ccdd431c)
      e860bbce
    • Peter Hutterer's avatar
      Xi: avoid integer truncation in length check of ProcXIChangeProperty · 8a1fa008
      Peter Hutterer authored
      
      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->num_items 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->num_items bytes, i.e. 4GB.
      
      The same bug exists in ProcChangeProperty and ProcXChangeDeviceProperty,
      so let's fix that too.
      
      CVE-2022-46344, ZDI-CAN 19405
      
      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>
      Acked-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit 8f454b79)
      8a1fa008
    • Peter Hutterer's avatar
      Xi: return an error from XI property changes if verification failed · 40f431de
      Peter Hutterer authored
      
      Both ProcXChangeDeviceProperty and ProcXIChangeProperty checked the
      property for validity but didn't actually return the potential error.
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Acked-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit b8a84cb0)
      40f431de
    • Peter Hutterer's avatar
      Xext: free the screen saver resource when replacing it · d6c7de9e
      Peter Hutterer authored
      
      This fixes a use-after-free bug:
      
      When a client first calls ScreenSaverSetAttributes(), a struct
      ScreenSaverAttrRec is allocated and added to the client's
      resources.
      
      When the same client calls ScreenSaverSetAttributes() again, a new
      struct ScreenSaverAttrRec is allocated, replacing the old struct. The
      old struct was freed but not removed from the clients resources.
      
      Later, when the client is destroyed the resource system invokes
      ScreenSaverFreeAttr and attempts to clean up the already freed struct.
      
      Fix this by letting the resource system free the old attrs instead.
      
      CVE-2022-46343, ZDI-CAN 19404
      
      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>
      Acked-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit 842ca3cc)
      d6c7de9e
    • Peter Hutterer's avatar
      Xext: free the XvRTVideoNotify when turning off from the same client · 67927cc4
      Peter Hutterer authored
      
      This fixes a use-after-free bug:
      
      When a client first calls XvdiSelectVideoNotify() on a drawable with a
      TRUE onoff argument, a struct XvVideoNotifyRec is allocated. This struct
      is added twice to the resources:
        - as the drawable's XvRTVideoNotifyList. This happens only once per
          drawable, subsequent calls append to this list.
        - as the client's XvRTVideoNotify. This happens for every client.
      
      The struct keeps the ClientPtr around once it has been added for a
      client. The idea, presumably, is that if the client disconnects we can remove
      all structs from the drawable's list that match the client (by resetting
      the ClientPtr to NULL), but if the drawable is destroyed we can remove
      and free the whole list.
      
      However, if the same client then calls XvdiSelectVideoNotify() on the
      same drawable with a FALSE onoff argument, only the ClientPtr on the
      existing struct was set to NULL. The struct itself remained in the
      client's resources.
      
      If the drawable is now destroyed, the resource system invokes
      XvdiDestroyVideoNotifyList which frees the whole list for this drawable
      - including our struct. This function however does not free the resource
      for the client since our ClientPtr is NULL.
      
      Later, when the client is destroyed and the resource system invokes
      XvdiDestroyVideoNotify, we unconditionally set the ClientPtr to NULL. On
      a struct that has been freed previously. This is generally frowned upon.
      
      Fix this by calling FreeResource() on the second call instead of merely
      setting the ClientPtr to NULL. This removes the struct from the client
      resources (but not from the list), ensuring that it won't be accessed
      again when the client quits.
      
      Note that the assignment tpn->client = NULL; is superfluous since the
      XvdiDestroyVideoNotify function will do this anyway. But it's left for
      clarity and to match a similar invocation in XvdiSelectPortNotify.
      
      CVE-2022-46342, ZDI-CAN 19400
      
      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>
      Acked-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit b79f32b5)
      67927cc4
    • Peter Hutterer's avatar
      Xi: disallow passive grabs with a detail > 255 · a6c0d7b1
      Peter Hutterer authored
      
      The XKB protocol effectively prevents us from ever using keycodes above
      255. For buttons it's theoretically possible but realistically too niche
      to worry about. For all other passive grabs, the detail must be zero
      anyway.
      
      This fixes an OOB write:
      
      ProcXIPassiveUngrabDevice() calls DeletePassiveGrabFromList with a
      temporary grab struct which contains tempGrab->detail.exact = stuff->detail.
      For matching existing grabs, DeleteDetailFromMask is called with the
      stuff->detail value. This function creates a new mask with the one bit
      representing stuff->detail cleared.
      
      However, the array size for the new mask is 8 * sizeof(CARD32) bits,
      thus any detail above 255 results in an OOB array write.
      
      CVE-2022-46341, ZDI-CAN 19381
      
      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>
      Acked-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit 51eb63b0)
      a6c0d7b1
Loading