Skip to content
Snippets Groups Projects
  1. Oct 29, 2024
  2. Oct 22, 2024
  3. Oct 12, 2024
  4. Oct 11, 2024
  5. Oct 10, 2024
  6. Sep 01, 2024
  7. Aug 23, 2024
  8. Jul 23, 2024
  9. May 12, 2024
    • José Expósito's avatar
      ephyr: Fix incompatible pointer type build error · 8407181c
      José Expósito authored and Gabi Falk's avatar Gabi Falk committed
      Fix a compilation error on 32 bits architectures with gcc 14:
      
        ephyr_glamor_xv.c: In function ‘ephyr_glamor_xv_init’:
        ephyr_glamor_xv.c:154:31: error: assignment to ‘SetPortAttributeFuncPtr’ {aka ‘int (*)(struct _KdScreenInfo *, long unsigned int,  int,  void *)’} from incompatible pointer type ‘int (*)(KdScreenInfo *, Atom,  INT32,  void *)’ {aka ‘int (*)(struct _KdScreenInfo *, long unsigned int,  long int,  void *)’} [-Wincompatible-pointer-types]
          154 |     adaptor->SetPortAttribute = ephyr_glamor_xv_set_port_attribute;
              |                               ^
        ephyr_glamor_xv.c:155:31: error: assignment to ‘GetPortAttributeFuncPtr’ {aka ‘int (*)(struct _KdScreenInfo *, long unsigned int,  int *, void *)’} from incompatible pointer type ‘int (*)(KdScreenInfo *, Atom,  INT32 *, void *)’ {aka ‘int (*)(struct _KdScreenInfo *, long unsigned int,  long int *, void *)’} [-Wincompatible-pointer-types]
          155 |     adaptor->GetPortAttribute = ephyr_glamor_xv_get_port_attribute;
              |                               ^
      
      Build error logs:
      https://koji.fedoraproject.org/koji/taskinfo?taskID=111964273
      
      
      
      Signed-off-by: default avatarJosé Expósito <jexposit@redhat.com>
      (cherry picked from commit e89edec4)
      
      Part-of: <!1532>
      8407181c
  10. Apr 12, 2024
  11. Apr 09, 2024
    • Olivier Fourdan's avatar
      render: Avoid possible double-free in ProcRenderAddGlyphs() · b4ea6f9e
      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: #1659
      
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Part-of: <!1476>
      (cherry picked from commit 337d8d48)
      b4ea6f9e
  12. Apr 05, 2024
    • Willem Jan Palenstijn's avatar
      mi: fix rounding issues around zero in miPointerSetPosition · f54647df
      Willem Jan Palenstijn authored and Peter Hutterer's avatar Peter Hutterer committed
      Fixes: #577
      
      
      
      This patch replaces the instances of trunc in miPointerSetPosition by
      floor, thereby removing the incorrect behaviour with subpixel pointer
      locations between -1 and 0.
      
      This is the relevant code fragment:
      
          /* In the event we actually change screen or we get confined, we just
           * drop the float component on the floor
           * FIXME: only drop remainder for ConstrainCursorHarder, not for screen
           * crossings */
          if (x != trunc(*screenx))
              *screenx = x;
          if (y != trunc(*screeny))
              *screeny = y;
      
      The behaviour of this code does not match its comment for subpixel
      coordinates between -1 and 0. For example, if *screenx is -0.5, the
      preceding code would (correctly) clamp x to 0, but this would not be
      detected by this condition, since 0 == trunc(-0.5), leaving *screenx
      at -0.5, out of bounds.
      
      This causes undesirable behaviour in GTK3 code using xi2, where negative
      subpixel coordinates like this would (to all appearances randomly)
      remove the focus from windows aligned with the zero boundary when the
      mouse hits the left or top screen boundaries.
      
      The other occurences of trunc in miPointerSetPosition have a more subtle
      effect which would prevent proper clamping if there is a pointer limit
      at a negative integer rather than at 0. This patch changes these to
      floor for consistency.
      
      Signed-off-by: default avatarWillem Jan Palenstijn <wjp@usecode.org>
      Part-of: <!1451>
      (cherry picked from commit 0ee4ed28)
      f54647df
  13. Apr 03, 2024
  14. Mar 27, 2024
  15. Mar 23, 2024
    • Peter Hutterer's avatar
      Allow disabling byte-swapped clients · 5d7272f0
      Peter Hutterer authored and Alan Coopersmith's avatar Alan Coopersmith committed
      
      The X server swapping code is a huge attack surface, much of this code
      is untested and prone to security issues. The use-case of byte-swapped
      clients is very niche, so allow users to disable this if they don't
      need it, using either a config option or commandline flag.
      
      For Xorg, this adds the ServerFlag "AllowByteSwappedClients" "off".
      For all DDX, this adds the commandline options +byteswappedclients and
      -byteswappedclients to enable or disable, respectively.
      
      Fixes #1201
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      ---
      (cherry picked from commit 41277766)
      (cherry picked from commit af5cd5ac)
      Backport to server-21.1-branch modified to keep byte-swapping enabled
      by default but easy to disable by users or admins (or even by distros
      shipping an xorg.conf.d fragment in their packages).
      
      Signed-off-by: default avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Part-of: <!1440>
      5d7272f0
  16. Feb 23, 2024
  17. Feb 19, 2024
  18. Jan 22, 2024
    • Povilas Kanapickas's avatar
      dix: Fix use after free in input device shutdown · 8b75ec34
      Povilas Kanapickas authored and Peter Hutterer's avatar Peter Hutterer committed
      
      This fixes access to freed heap memory via dev->master. E.g. when
      running BarrierNotify.ReceivesNotifyEvents/7 test from
      xorg-integration-tests:
      
      ==24736==ERROR: AddressSanitizer: heap-use-after-free on address
      0x619000065020 at pc 0x55c450e2b9cf bp 0x7fffc532fd20 sp 0x7fffc532fd10
      READ of size 4 at 0x619000065020 thread T0
          #0 0x55c450e2b9ce in GetMaster ../../../dix/devices.c:2722
          #1 0x55c450e9d035 in IsFloating ../../../dix/events.c:346
          #2 0x55c4513209c6 in GetDeviceUse ../../../Xi/xiquerydevice.c:525
      ../../../Xi/xichangehierarchy.c:95
          #4 0x55c450e3455c in RemoveDevice ../../../dix/devices.c:1204
      ../../../hw/xfree86/common/xf86Xinput.c:1142
          #6 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
          #7 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
          #8 0x55c450e837ef in dix_main ../../../dix/main.c:302
          #9 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
      (/lib/x86_64-linux-gnu/libc.so.6+0x28564)
          #11 0x55c450d0113d in _start (/usr/lib/xorg/Xorg+0x117713d)
      
      0x619000065020 is located 160 bytes inside of 912-byte region
      [0x619000064f80,0x619000065310)
      freed by thread T0 here:
      (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
          #1 0x55c450e19f1c in CloseDevice ../../../dix/devices.c:1014
          #2 0x55c450e343a4 in RemoveDevice ../../../dix/devices.c:1186
      ../../../hw/xfree86/common/xf86Xinput.c:1142
          #4 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
          #5 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
          #6 0x55c450e837ef in dix_main ../../../dix/main.c:302
          #7 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
      (/lib/x86_64-linux-gnu/libc.so.6+0x28564)
      
      previously allocated by thread T0 here:
      (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
          #1 0x55c450e1c57b in AddInputDevice ../../../dix/devices.c:259
          #2 0x55c450e34840 in AllocDevicePair ../../../dix/devices.c:2755
          #3 0x55c45130318f in add_master ../../../Xi/xichangehierarchy.c:152
      ../../../Xi/xichangehierarchy.c:465
          #5 0x55c4512cb9f5 in ProcIDispatch ../../../Xi/extinit.c:390
          #6 0x55c450e6a92b in Dispatch ../../../dix/dispatch.c:551
          #7 0x55c450e834b7 in dix_main ../../../dix/main.c:272
          #8 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
      (/lib/x86_64-linux-gnu/libc.so.6+0x28564)
      
      The problem is caused by dev->master being not reset when disabling the
      device, which then causes dangling pointer when the master device itself
      is being deleted when exiting whole server.
      
      Note that RecalculateMasterButtons() requires dev->master to be still
      valid, so we can reset it only at the end of function.
      
      Signed-off-by: default avatarPovilas Kanapickas <povilas@radix.lt>
      (cherry picked from commit 1801fe0a)
      8b75ec34
  19. Jan 16, 2024
    • José Expósito's avatar
      xserver 21.1.11 · 31407c01
      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 · a4f0e946
      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)
      a4f0e946
    • Olivier Fourdan's avatar
      glx: Call XACE hooks on the GLX buffer · 8d825f72
      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)
      8d825f72
    • Peter Hutterer's avatar
      dix: when disabling a master, float disabled slaved devices too · 5c4816af
      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)
      5c4816af
Loading