Skip to content
Snippets Groups Projects
  1. May 15, 2024
  2. May 13, 2024
  3. May 03, 2024
    • Olivier Fourdan's avatar
      xwayland: Do not remove output on withdraw if leased · 67284dea
      Olivier Fourdan authored
      
      On DRM lease connector withdrawn event, Xwayland would free the
      corresponding xwl_output offered for lease.
      
      However, the pointer is still referenced from the rrLease->outputs[],
      meaning that trying to clean up the RANDR DRM leases as done with commit
      ef181265 (xwayland: Clean up drm lease when terminating) would cause a
      use after free and random crashes.
      
      To avoid that issue, on the connector withdraw event, set the connector
      withdrawn flag but do not to remove (i.e. free) the xwayland output if
      its is offered for lease.
      
      Then, once the lease is terminated, check for the xwl_outputs with a
      withdrawn connector and remove them (once we have no use for them
      anymore.
      
      Note that we cannot do that cleanup from xwl_randr_terminate_lease() as
      removing the xwl_output will free the RRcrtc resources, which checks for
      leases in XRANDR, and calls RRTerminateLease(), which chains back to
      xwl_randr_terminate_lease().
      
      v2: Use a "withdrawn_connector" flag to mark outputs to remove (Xaver)
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarXaver Hugl <xaver.hugl@kde.org>
      fixes: ef181265 - xwayland: Clean up drm lease when terminating
      
      See-also: #946
      See-also: !1130
      (cherry picked from commit 40537824)
      
      Part-of: <!1515>
      67284dea
    • Olivier Fourdan's avatar
      xwayland: Check for outputs before lease devices · 2a391d68
      Olivier Fourdan authored
      
      In xwl_randr_request_lease(), the code checks first for leased device,
      and then checks for existing output for lease.
      
      The former assumes there are outputs for lease whereas the latter checks
      for the output, connector and lease.
      
      So if there is any existing rrLease->outputs[]->devPrivate unset, the
      code would crash on a NULL pointer dereference on the first sanity check
      before having a chance to reach the second check that would have caught
      the problem.
      
      Invert the sanity checks so that we would catch this first and return a
      BadValue instead of possibly segfaulting.
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarXaver Hugl <xaver.hugl@kde.org>
      (cherry picked from commit 21916ae1)
      
      Part-of: <!1515>
      2a391d68
    • Michel Dänzer's avatar
      xwayland/glamor: Handle depth 15 in gbm_format_for_depth · b241a9e1
      Michel Dänzer authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Prevents Xwayland with glamor from logging
      
       unexpected depth: 15
      
      to stderr many times when running
      
       rendercheck -t blend -o clear
      
      (cherry picked from commit 08113b89)
      
      Part-of: <!1515>
      b241a9e1
    • Michel Dänzer's avatar
      dri3: Free formats in cache_formats_and_modifiers · 05150863
      Michel Dänzer authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Fixes leak:
      
      ==15672== 60 bytes in 1 blocks are definitely lost in loss record 3,803 of 8,127
      ==15672==    at 0x4840718: malloc (vg_replace_malloc.c:392)
      ==15672==    by 0x2F2698: XNFreallocarray (alloc.c:55)
      ==15672==    by 0x1ADAA9: xwl_dmabuf_get_formats_for_device (xwayland-dmabuf.c:207)
      ==15672==    by 0x1ADAA9: xwl_glamor_get_formats (xwayland-dmabuf.c:248)
      ==15672==    by 0x303D86: cache_formats_and_modifiers (dri3_screen.c:176)
      ==15672==    by 0x303D86: dri3_get_supported_modifiers (dri3_screen.c:229)
      ==15672==    by 0x30331A: proc_dri3_get_supported_modifiers (dri3_request.c:389)
      ==15672==    by 0x217B6B: Dispatch (dispatch.c:550)
      ==15672==    by 0x21B9A0: dix_main (main.c:276)
      ==15672==    by 0x51086C9: (below main) (libc_start_call_main.h:58)
      
      Fixes: a42992a4 ("dri3: rework format/modifier caching")
      (cherry picked from commit 3b6b88c1)
      
      Part-of: <!1515>
      05150863
    • Michel Dänzer's avatar
      xwayland: Use drmDevicesEqual in xwl_dmabuf_feedback_tranche_done · fc3b7c9a
      Michel Dänzer authored and Olivier Fourdan's avatar Olivier Fourdan committed
      xwl_dmabuf_feedback_tranche_target_device always allocates a new
      drmDevice for xwl_feedback->tmp_tranche.drm_dev, so the pointers are
      never equal here.
      
      Fixes: 6f0b9dee ("xwayland: use drmDevice to compare DRM devices")
      
      v2:
      * Flip order of checks, so drmDevicesEqual is called only if the
        supports_scanout flags match.
      
      (cherry picked from commit 4dc7e998)
      
      Part-of: <!1515>
      fc3b7c9a
    • Michel Dänzer's avatar
      xwayland: Call drmFreeDevice for dma-buf default feedback · 2b260514
      Michel Dänzer authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Fixes leaks:
      
      ==13712== 144 bytes in 1 blocks are definitely lost in loss record 4,827 of 7,462
      ==13712==    at 0x48459F3: calloc (vg_replace_malloc.c:1340)
      ==13712==    by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072)
      ==13712==    by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104)
      ==13712==    by 0x49BFAC9: process_device (xf86drm.c:4508)
      ==13712==    by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670)
      ==13712==    by 0x1AD370: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477)
      ==13712==    by 0x53C03FD: ffi_call_unix64 (unix64.S:104)
      ==13712==    by 0x53BF70C: ffi_call_int (ffi64.c:673)
      ==13712==    by 0x53BFEE2: ffi_call (ffi64.c:710)
      ==13712==    by 0x49AC920: wl_closure_invoke (connection.c:1025)
      ==13712==    by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631)
      ==13712==    by 0x49AA5AB: dispatch_queue (wayland-client.c:1777)
      ==13712==    by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019)
      ==13712==    by 0x49AAB5E: wl_display_roundtrip_queue (wayland-client.c:1403)
      
      ==13712== 576 bytes in 4 blocks are definitely lost in loss record 6,289 of 7,462
      ==13712==    at 0x48459F3: calloc (vg_replace_malloc.c:1340)
      ==13712==    by 0x49BE94D: drmDeviceAlloc (xf86drm.c:4072)
      ==13712==    by 0x49BFAC9: drmProcessPciDevice (xf86drm.c:4104)
      ==13712==    by 0x49BFAC9: process_device (xf86drm.c:4508)
      ==13712==    by 0x49C35FB: drmGetDeviceFromDevId (xf86drm.c:4670)
      ==13712==    by 0x1AD583: xwl_dmabuf_feedback_main_device (xwayland-dmabuf.c:477)
      ==13712==    by 0x1AD583: xwl_window_dmabuf_feedback_main_device (xwayland-dmabuf.c:691)
      ==13712==    by 0x53C03FD: ffi_call_unix64 (unix64.S:104)
      ==13712==    by 0x53BF70C: ffi_call_int (ffi64.c:673)
      ==13712==    by 0x53BFEE2: ffi_call (ffi64.c:710)
      ==13712==    by 0x49AC920: wl_closure_invoke (connection.c:1025)
      ==13712==    by 0x49A8C08: dispatch_event.isra.0 (wayland-client.c:1631)
      ==13712==    by 0x49AA5AB: dispatch_queue (wayland-client.c:1777)
      ==13712==    by 0x49AA5AB: wl_display_dispatch_queue_pending (wayland-client.c:2019)
      ==13712==    by 0x1A1842: xwl_read_events (xwayland-screen.c:566)
      ==13712==    by 0x1A1842: xwl_read_events (xwayland-screen.c:553)
      
      Fixes: 6f0b9dee ("xwayland: use drmDevice to compare DRM devices")
      (cherry picked from commit 82d3b8ff)
      
      Part-of: <!1515>
      2b260514
  4. Apr 17, 2024
  5. Apr 09, 2024
    • Olivier Fourdan's avatar
      Bump version to 23.2.6 · db9cde03
      Olivier Fourdan authored
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Part-of: <xorg/xserver!1480>
    • Olivier Fourdan's avatar
      render: Avoid possible double-free in ProcRenderAddGlyphs() · c3c2218a
      Olivier Fourdan authored
      ProcRenderAddGlyphs() adds the glyph to the glyphset using AddGlyph() and
      then frees it using FreeGlyph() to decrease the reference count, after
      AddGlyph() has increased it.
      
      AddGlyph() however may chose to reuse an existing glyph if it's already
      in the glyphSet, and free the glyph that was given, in which case the
      caller function, ProcRenderAddGlyphs() will call FreeGlyph() on an
      already freed glyph, as reported by ASan:
      
        READ of size 4 thread T0
          #0 in FreeGlyph xserver/render/glyph.c:252
          #1 in ProcRenderAddGlyphs xserver/render/render.c:1174
          #2 in Dispatch xserver/dix/dispatch.c:546
          #3 in dix_main xserver/dix/main.c:271
          #4 in main xserver/dix/stubmain.c:34
          #5 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
          #6 in __libc_start_main_impl ../csu/libc-start.c:360
          #7  (/usr/bin/Xwayland+0x44fe4)
        Address is located 0 bytes inside of 64-byte region
        freed by thread T0 here:
          #0 in __interceptor_free libsanitizer/asan/asan_malloc_linux.cpp:52
          #1 in _dixFreeObjectWithPrivates xserver/dix/privates.c:538
          #2 in AddGlyph xserver/render/glyph.c:295
          #3 in ProcRenderAddGlyphs xserver/render/render.c:1173
          #4 in Dispatch xserver/dix/dispatch.c:546
          #5 in dix_main xserver/dix/main.c:271
          #6 in main xserver/dix/stubmain.c:34
          #7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        previously allocated by thread T0 here:
          #0 in __interceptor_malloc libsanitizer/asan/asan_malloc_linux.cpp:69
          #1 in AllocateGlyph xserver/render/glyph.c:355
          #2 in ProcRenderAddGlyphs xserver/render/render.c:1085
          #3 in Dispatch xserver/dix/dispatch.c:546
          #4 in dix_main xserver/dix/main.c:271
          #5 in main xserver/dix/stubmain.c:34
          #6 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        SUMMARY: AddressSanitizer: heap-use-after-free xserver/render/glyph.c:252 in FreeGlyph
      
      To avoid that, make sure not to free the given glyph in AddGlyph().
      
      v2: Simplify the test using the boolean returned from AddGlyph() (Michel)
      v3: Simplify even more by not freeing the glyph in AddGlyph() (Peter)
      
      Fixes: bdca6c3d - render: fix refcounting of glyphs during ProcRenderAddGlyphs
      Closes: xorg/xserver#1659
      
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit 337d8d48)
      
      Part-of: <xorg/xserver!1478>
      c3c2218a
  6. Apr 04, 2024
    • Florian Weimer's avatar
      xwayland: Use correct pointer types on i386 · f69899a4
      Florian Weimer authored and Peter Hutterer's avatar Peter Hutterer committed
      And other 32-bit architectures, where uint32_t and CARD32 are
      not the same type.  Otherwise the build will fail with GCC 14
      with errors like:
      
      ../hw/xwayland/xwayland-glamor.c: In function ‘xwl_glamor_get_formats’:
      ../hw/xwayland/xwayland-glamor.c:291:43: error: passing argument 3 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types]
        291 |                                           num_formats, formats);
            |                                           ^~~~~~~~~~~
            |                                           |
            |                                           CARD32 * {aka long unsigned int *}
      ../hw/xwayland/xwayland-glamor.c:238:38: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’}
        238 |                            uint32_t *num_formats, uint32_t **formats)
            |                            ~~~~~~~~~~^~~~~~~~~~~
      ../hw/xwayland/xwayland-glamor.c:291:56: error: passing argument 4 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types]
        291 |                                           num_formats, formats);
            |                                                        ^~~~~~~
            |                                                        |
            |                                                        CARD32 ** {aka long unsigned int **}
      ../hw/xwayland/xwayland-glamor.c:238:62: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’}
        238 |                            uint32_t *num_formats, uint32_t **formats)
            |                                                   ~~~~~~~~~~~^~~~~~~
      ../hw/xwayland/xwayland-glamor.c:295:28: error: passing argument 3 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types]
        295 |                            num_formats, formats);
            |                            ^~~~~~~~~~~
            |                            |
            |                            CARD32 * {aka long unsigned int *}
      ../hw/xwayland/xwayland-glamor.c:217:26: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’}
        217 |                uint32_t *num_formats, uint32_t **formats)
            |                ~~~~~~~~~~^~~~~~~~~~~
      ../hw/xwayland/xwayland-glamor.c:295:41: error: passing argument 4 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types]
        295 |                            num_formats, formats);
            |                                         ^~~~~~~
            |                                         |
            |                                         CARD32 ** {aka long unsigned int **}
      ../hw/xwayland/xwayland-glamor.c:217:50: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’}
        217 |                uint32_t *num_formats, uint32_t **formats)
            |                                       ~~~~~~~~~~~^~~~~~~
      
      (cherry picked from commit f0a187f5)
      
      Part-of: <xorg/xserver!1470>
      f69899a4
  7. Apr 03, 2024
  8. Apr 02, 2024
  9. Feb 08, 2024
    • Warren Togami's avatar
      xwayland: Ensure pointer for gestures has buttons · d755da58
      Warren Togami authored and Olivier Fourdan's avatar Olivier Fourdan committed
      X11 clients tend to assume that pointers have buttons. This
      assumption means they often fail to handle the X error that
      is generated when querying the button mapping of a pointer
      device that lacks buttons.
      
      This failure to handle the X error leads to those client
      applications to abruptly exit.
      
      This commit assigns vestigial buttons to the gesture pointer
      device for the sole purpose of backward compatibility with
      legacy X11 clients.
      
      That technique is already employed for a different pointer,
      the relative pointer device, for similar reasons, so this
      just makes the legacy client compatibility more complete.
      
      See https://gitlab.gnome.org/GNOME/mutter/-/issues/2353
      
      (cherry picked from commit 456b0e86)
      d755da58
  10. Jan 16, 2024
    • José Expósito's avatar
      Bump version to 23.2.4 · 4f16a3f0
      José Expósito authored
      
      Signed-off-by: default avatarJosé Expósito <jose.exposito89@gmail.com>
    • Olivier Fourdan's avatar
      ephyr,xwayland: Use the proper private key for cursor · 51be9e76
      Olivier Fourdan authored and José Expósito's avatar José Expósito committed
      
      The cursor in DIX is actually split in two parts, the cursor itself and
      the cursor bits, each with their own devPrivates.
      
      The cursor itself includes the cursor bits, meaning that the cursor bits
      devPrivates in within structure of the cursor.
      
      Both Xephyr and Xwayland were using the private key for the cursor bits
      to store the data for the cursor, and when using XSELINUX which comes
      with its own special devPrivates, the data stored in that cursor bits'
      devPrivates would interfere with the XSELINUX devPrivates data and the
      SELINUX security ID would point to some other unrelated data, causing a
      crash in the XSELINUX code when trying to (re)use the security ID.
      
      CVE-2024-0409
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 2ef0f111)
      51be9e76
    • Olivier Fourdan's avatar
      glx: Call XACE hooks on the GLX buffer · 4093057b
      Olivier Fourdan authored and José Expósito's avatar José Expósito committed
      
      The XSELINUX code will label resources at creation by checking the
      access mode. When the access mode is DixCreateAccess, it will call the
      function to label the new resource SELinuxLabelResource().
      
      However, GLX buffers do not go through the XACE hooks when created,
      hence leaving the resource actually unlabeled.
      
      When, later, the client tries to create another resource using that
      drawable (like a GC for example), the XSELINUX code would try to use
      the security ID of that object which has never been labeled, get a NULL
      pointer and crash when checking whether the requested permissions are
      granted for subject security ID.
      
      To avoid the issue, make sure to call the XACE hooks when creating the
      GLX buffers.
      
      Credit goes to Donn Seeley <donn@xmission.com> for providing the patch.
      
      CVE-2024-0408
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Acked-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit e5e8586a)
      4093057b
    • Peter Hutterer's avatar
      dix: when disabling a master, float disabled slaved devices too · 42f8d182
      Peter Hutterer authored and José Expósito's avatar José Expósito committed
      Disabling a master device floats all slave devices but we didn't do this
      to already-disabled slave devices. As a result those devices kept their
      reference to the master device resulting in access to already freed
      memory if the master device was removed before the corresponding slave
      device.
      
      And to match this behavior, also forcibly reset that pointer during
      CloseDownDevices().
      
      Related to CVE-2024-21886, ZDI-CAN-22840
      
      (cherry picked from commit 26769aa7)
      42f8d182
    • José Expósito's avatar
      Xi: do not keep linked list pointer during recursion · 01cd3a72
      José Expósito authored and José Expósito's avatar José Expósito committed
      The `DisableDevice()` function is called whenever an enabled device
      is disabled and it moves the device from the `inputInfo.devices` linked
      list to the `inputInfo.off_devices` linked list.
      
      However, its link/unlink operation has an issue during the recursive
      call to `DisableDevice()` due to the `prev` pointer pointing to a
      removed device.
      
      This issue leads to a length mismatch between the total number of
      devices and the number of device in the list, leading to a heap
      overflow and, possibly, to local privilege escalation.
      
      Simplify the code that checked whether the device passed to
      `DisableDevice()` was in `inputInfo.devices` or not and find the
      previous device after the recursion.
      
      CVE-2024-21886, ZDI-CAN-22840
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit bc1fdbe4)
      01cd3a72
    • Peter Hutterer's avatar
      Xi: flush hierarchy events after adding/removing master devices · 7efd09cd
      Peter Hutterer authored and José Expósito's avatar José Expósito committed
      The `XISendDeviceHierarchyEvent()` function allocates space to store up
      to `MAXDEVICES` (256) `xXIHierarchyInfo` structures in `info`.
      
      If a device with a given ID was removed and a new device with the same
      ID added both in the same operation, the single device ID will lead to
      two info structures being written to `info`.
      
      Since this case can occur for every device ID at once, a total of two
      times `MAXDEVICES` info structures might be written to the allocation.
      
      To avoid it, once one add/remove master is processed, send out the
      device hierarchy event for the current state and continue. That event
      thus only ever has exactly one of either added/removed in it (and
      optionally slave attached/detached).
      
      CVE-2024-21885, ZDI-CAN-22744
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit 4a5e9b18)
      7efd09cd
    • Peter Hutterer's avatar
      Xi: when creating a new ButtonClass, set the number of buttons · 1c22e4a3
      Peter Hutterer authored and José Expósito's avatar José Expósito committed
      There's a racy sequence where a master device may copy the button class
      from the slave, without ever initializing numButtons. This leads to a
      device with zero buttons but a button class which is invalid.
      
      Let's copy the numButtons value from the source - by definition if we
      don't have a button class yet we do not have any other slave devices
      with more than this number of buttons anyway.
      
      CVE-2024-0229, ZDI-CAN-22678
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit df3c6570)
      1c22e4a3
    • Peter Hutterer's avatar
      dix: fix DeviceStateNotify event calculation · ee5377d9
      Peter Hutterer authored and José Expósito's avatar José Expósito committed
      The previous code only made sense if one considers buttons and keys to
      be mutually exclusive on a device. That is not necessarily true, causing
      a number of issues.
      
      This function allocates and fills in the number of xEvents we need to
      send the device state down the wire.  This is split across multiple
      32-byte devices including one deviceStateNotify event and optional
      deviceKeyStateNotify, deviceButtonStateNotify and (possibly multiple)
      deviceValuator events.
      
      The previous behavior would instead compose a sequence
      of [state, buttonstate, state, keystate, valuator...]. This is not
      protocol correct, and on top of that made the code extremely convoluted.
      
      Fix this by streamlining: add both button and key into the deviceStateNotify
      and then append the key state and button state, followed by the
      valuators. Finally, the deviceValuator events contain up to 6 valuators
      per event but we only ever sent through 3 at a time. Let's double that
      troughput.
      
      CVE-2024-0229, ZDI-CAN-22678
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit 219c54b8)
      ee5377d9
    • Peter Hutterer's avatar
      dix: Allocate sufficient xEvents for our DeviceStateNotify · 9105be1c
      Peter Hutterer authored and José Expósito's avatar José Expósito committed
      If a device has both a button class and a key class and numButtons is
      zero, we can get an OOB write due to event under-allocation.
      
      This function seems to assume a device has either keys or buttons, not
      both. It has two virtually identical code paths, both of which assume
      they're applying to the first event in the sequence.
      
      A device with both a key and button class triggered a logic bug - only
      one xEvent was allocated but the deviceStateNotify pointer was pushed on
      once per type. So effectively this logic code:
      
         int count = 1;
         if (button && nbuttons > 32) count++;
         if (key && nbuttons > 0) count++;
         if (key && nkeys > 32) count++; // this is basically always true
         // count is at 2 for our keys + zero button device
      
         ev = alloc(count * sizeof(xEvent));
         FixDeviceStateNotify(ev);
         if (button)
           FixDeviceStateNotify(ev++);
         if (key)
           FixDeviceStateNotify(ev++);   // santa drops into the wrong chimney here
      
      If the device has more than 3 valuators, the OOB is pushed back - we're
      off by one so it will happen when the last deviceValuator event is
      written instead.
      
      Fix this by allocating the maximum number of events we may allocate.
      Note that the current behavior is not protocol-correct anyway, this
      patch fixes only the allocation issue.
      
      Note that this issue does not trigger if the device has at least one
      button. While the server does not prevent a button class with zero
      buttons, it is very unlikely.
      
      CVE-2024-0229, ZDI-CAN-22678
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit ece23be8)
      9105be1c
    • Peter Hutterer's avatar
      dix: allocate enough space for logical button maps · b5cb2703
      Peter Hutterer authored and José Expósito's avatar José Expósito committed
      Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for
      each logical button currently down. Since buttons can be arbitrarily mapped
      to anything up to 255 make sure we have enough bits for the maximum mapping.
      
      CVE-2023-6816, ZDI-CAN-22664, ZDI-CAN-22665
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      (cherry picked from commit 9e2ecb2a)
      b5cb2703
  11. Jan 11, 2024
  12. Dec 13, 2023
Loading