summaryrefslogtreecommitdiff
path: root/Xi
Commit message (Collapse)AuthorAgeFilesLines
* Xi: fix potential use-after-free in DeepCopyPointerClassesPeter Hutterer2023-02-071-1/+3
| | | | | | | | | CVE-2023-0494, ZDI-CAN-19596 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Xi: avoid integer truncation in length check of ProcXIChangePropertyPeter Hutterer2022-12-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com>
* Xi: return an error from XI property changes if verification failedPeter Hutterer2022-12-141-0/+5
| | | | | | | | Both ProcXChangeDeviceProperty and ProcXIChangeProperty checked the property for validity but didn't actually return the potential error. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com>
* Xi: disallow passive grabs with a detail > 255Peter Hutterer2022-12-141-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com>
* dix: Correctly save replayed event into GrabInfoRecPovilas Kanapickas2022-02-091-1/+1
| | | | | | | | | | | | | | | | | | | When processing events we operate on InternalEvent pointers. They may actually refer to a an instance of DeviceEvent, GestureEvent or any other event that comprises the InternalEvent union. This works well in practice because we always look into event type before doing anything, except in the case of copying the event. *dst_event = *src_event would copy whole InternalEvent event and would cause out of bounds read in case the pointed to event was not InternalEvent but e.g. DeviceEvent. This regression has been introduced in 23a8b62d34344575f9df9d057fb74bfefa94a77b. Fixes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1261 Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
* Convert more funcs to use InternalEvent.Matthieu Herrb2021-12-191-2/+2
| | | | | | | | | | | This fixes a crash when a DeviceEvent struct converted to InteralEvent was beeing copied as InternalEvent (and thus causing out of bounds reads) in ActivateGrabNoDelivery() in events.c: 3876 *grabinfo->sync.event = *real_event; Possible fix for https://gitlab.freedesktop.org/xorg/xserver/-/issues/1253 Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
* Remove autotools supportPovilas Kanapickas2021-10-271-111/+0
| | | | Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
* xinput: Silence a warning from gcc 11Adam Jackson2021-08-171-1/+1
| | | | | | | | | | | [45/388] Compiling C object Xi/liblibxserver_xi.a.p/xichangehierarchy.c.o ../Xi/xichangehierarchy.c:61:32: warning: argument 1 of type ‘int[256]’ with mismatched bound [-Warray-parameter=] 61 | XISendDeviceHierarchyEvent(int flags[MAXDEVICES]) | ~~~~^~~~~~~~~~~~~~~~~ In file included from ../Xi/xichangehierarchy.c:54: ../Xi/xichangehierarchy.h:42:37: note: previously declared as ‘int[]’ 42 | void XISendDeviceHierarchyEvent(int flags[]); | ~~~~^~~~~~~
* Xi: Work around broken libxcb that doesn't ignore unknown device classesPovilas Kanapickas2021-05-301-1/+20
| | | | | | | | | | | | | | libxcb 14.1 and older are not forwards-compatible with new device classes as it does not properly ignore unknown device classes. Since breaking libxcb would break quite a lot of applications, we instead report Gesture device class only if the client advertised support for XI 2.4. Clients may still not work in cases when a client advertises XI 2.4 support and then a completely separate module within the client uses broken libxcb to call XIQueryDevice. Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
* Xi: Implement gesture support for XIQueryDevicePovilas Kanapickas2021-05-301-1/+37
|
* Xi: Include gestures among events that may freeze devicePovilas Kanapickas2021-05-301-1/+6
|
* Implement gesture processing logicPovilas Kanapickas2021-05-301-0/+174
|
* dix: Implement internal gesture state handlingPovilas Kanapickas2021-05-301-0/+19
|
* xi: Implement conversions from internal to Xi2 gesture event structsPovilas Kanapickas2021-05-301-0/+80
|
* xi: Implement selection logic for gesture event typesPovilas Kanapickas2021-05-301-2/+51
|
* xi: Implement grab support for new gesture event typesPovilas Kanapickas2021-05-302-7/+28
|
* dix: Add new internal event enums for gesture eventsPovilas Kanapickas2021-05-301-0/+44
|
* Fix XChangeFeedbackControl() request underflowMatthieu Herrb2021-04-131-1/+4
| | | | | | | | | CVE-2021-3472 / ZDI-CAN-1259 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
* Xi: Deliver pointer emulated touch events to grabbing clientPovilas Kanapickas2021-02-151-10/+10
| | | | | | | | | | | | | | | | | | | | | | Delivery of emulated events usually happens only to the owning client. If there are grabs, only the grabbing client may receive these events. This logic does not work during the touch event replay in DeactivatePointerGrab(), as the previous grab is no longer in the listener queue of the touch, so the next owner gets whole emulated event sequence. This may trigger implicit grabs. After replay, DeactivatePointerGrab() will update the global grab without regard to this new implicit grab, which leads to issues down the line. This change is effectively the same as 35e5a76cc1 except that the change is limited to only emulated pointer events. Otherwise, in the case of a device grab we end up not sending any touch events to clients that selected XI_TouchOwnership event and should get touch events before they get ownership of touch sequence. Fixes #7 https://bugs.freedesktop.org/show_bug.cgi?id=96536
* Revert "Xi: Use current device active grab to deliver touch events if any"Povilas Kanapickas2021-02-151-8/+12
| | | | This reverts commit 98e3db2ac43d4a3f13475cb160c8ce0155ac7d61.
* xi: Don't deliver emulated motion when there's no owner for touch endPovilas Kanapickas2021-01-051-1/+8
| | | | | | | | | | | | | | | | | | | | | | Pointer-emulated touch events should only be delivered to the client that owns the sequence even if it's a core client that became the effective owner of the sequency by selecting for pointer press and movement. Currently the emulated events are delivered like this already (see TouchResourceIsOwner() check in DeliverEmulatedMotionEvent()), except in the case of TouchEnd, in which case the generated motion event is still delivered to some client that's not necessarily the owner of the touch sequence. We already know whether a touch sequence that is about to emulate a pointer event has an owner, we just need to check that. This further allows to simplify DeliverEmulatedMotionEvent() as it won't ever be called for non-owned touch events. https://bugs.freedesktop.org/show_bug.cgi?id=60394 Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
* dix: Store replayed event into GrabInfoRec struct as InternalEvent*Povilas Kanapickas2020-11-251-1/+1
|
* dix: Rename LISTENER_* to TOUCH_LISTENER_*Povilas Kanapickas2020-11-251-48/+48
|
* Xi: Make check_for_touch_selection_conflicts() more genericPovilas Kanapickas2020-11-251-5/+8
|
* Fix XIChangeHierarchy() integer underflowMatthieu Herrb2020-08-251-1/+1
| | | | | | | | | CVE-2020-14346 / ZDI-CAN-11429 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
* Fix spelling/wording issuesAlan Coopersmith2020-07-054-7/+7
| | | | | | | | Most (but not all) of these were found by using codespell --builtin clear,rare,usage,informal,code,names but not everything reported by that was fixed. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* xinput: Remove PropagateMaskAdam Jackson2020-03-303-40/+14
| | | | | | Initialized to a constant value, never modified, never varied by device. Signed-off-by: Adam Jackson <ajax@redhat.com>
* xinput: Remove ExtExclusiveMasksAdam Jackson2020-03-302-23/+1
| | | | | | Initialized to a constant value, never modified, never varied by device. Signed-off-by: Adam Jackson <ajax@redhat.com>
* Xi: return AlreadyGrabbed for key grabs > 255Peter Hutterer2019-06-121-2/+8
| | | | | | | | | | | | We can't have high keycodes because everything in XKB relies on 8 bits. XI2's API allows for 32-bit keycodes so we have to take those but nothing in the server is really ready for this. The effect of this right now is that any high keycode grab is clipped to 255 and thus ends up grabbing a different key instead. https://bugzilla.redhat.com/show_bug.cgi?id=1697804 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Xi: lock the input thread for any pointer barrier list manipulationPeter Hutterer2019-02-141-0/+10
| | | | | | | | | The input thread checks the barriers for pointer positioning, swapping the list out from underneath is considered impolite. Reported-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
* Xi: Use current device active grab to deliver touch events if anyMarco Trevisan (Treviño)2018-11-121-13/+8
| | | | | | | | | | | | When Retrieving touch delivery data we need to check if we have an active grab on such device, and in that case use it to delivery events. If we don't do this, when rejecting the touch events in DeactivatePointerGrab, we will end-up in creating an implicit grab that will change the device deviceGrab's state, causing a recursion during TouchEndTouch. Fixes #7 https://bugs.freedesktop.org/show_bug.cgi?id=96536
* Remove obsolete B16 & B32 tags in struct definitionsAlan Coopersmith2018-11-101-2/+2
| | | | | | | | They were defined as empty macros on all platforms except for the long unsupported Cray systems which needed to use bitfields to define types smaller than 64-bits. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* xi: free modifiers_failed on error path. (v2)Dave Airlie2018-09-121-2/+2
| | | | | | | | Pointed out by coverity. v2: set modifies_failed to NULL at start (whot) Signed-off-by: Dave Airlie <airlied@redhat.com>
* Xi: add forgotten byte-swaps for Valuator fieldsRoman Kapl2018-06-081-0/+3
| | | | | | | This has caused nonsensical values in xinput output. Signed-off-by: Roman Kapl <code@rkapl.cz> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Xi: fix byte-swapping of button labelsRoman Kapl2018-06-081-6/+20
| | | | | | | | | | | | | The byte-swapping code forgot that the xXIButtonInfo is followed by a button mask, not directly by the button labels. This resulted in client crashes in cross-endian setups, for example in `xinput list --long`, since the client got an invalid atom. A new function was introduced to get the right positions for the label and mask data. Signed-off-by: Roman Kapl <code@rkapl.cz> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Use ARRAY_SIZE all over the treeDaniel Martin2017-10-301-4/+2
| | | | | | | | | | Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with the ARRAY_SIZE macro from dix.h when possible. A semantic patch for coccinelle has been used first. Additionally, a few macros have been inlined as they had only one or two users. Signed-off-by: Daniel Martin <consume.noise@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
* Xi: fix wrong extra length check in ProcXIChangeHierarchy (CVE-2017-12178)Nathan Kidd2017-10-101-1/+1
| | | | | | | | Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Nathan Kidd <nkidd@opentext.com> Signed-off-by: Julien Cristau <jcristau@debian.org>
* Xi: integer overflow and unvalidated length in (S)ProcXIBarrierReleasePointerNathan Kidd2017-10-101-0/+5
| | | | | | | | | | | | | | | [jcristau: originally this patch fixed the same issue as commit 211e05ac85 "Xi: Test exact size of XIBarrierReleasePointer", with the addition of these checks] This addresses CVE-2017-12179 Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Signed-off-by: Nathan Kidd <nkidd@opentext.com> Signed-off-by: Julien Cristau <jcristau@debian.org>
* Xi: Test exact size of XIBarrierReleasePointerMichal Srb2017-07-111-3/+6
| | | | | | Otherwise a client can send any value of num_barriers and cause reading or swapping of values on heap behind the receive buffer. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Xi: Do not try to swap GenericEvent.Michal Srb2017-06-191-1/+9
| | | | | | | | | | | | The SProcXSendExtensionEvent must not attempt to swap GenericEvent because it is assuming that the event has fixed size and gives the swapping function xEvent-sized buffer. A GenericEvent would be later rejected by ProcXSendExtensionEvent anyway. Signed-off-by: Michal Srb <msrb@suse.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Xi: Verify all events in ProcXSendExtensionEvent.Michal Srb2017-06-191-5/+7
| | | | | | | | | | The requirement is that events have type in range EXTENSION_EVENT_BASE..lastEvent, but it was tested only for first event of all. Signed-off-by: Michal Srb <msrb@suse.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Xi: Zero target buffer in SProcXSendExtensionEvent.Michal Srb2017-06-191-1/+1
| | | | | | | | | | | | | | | | Make sure that the xEvent eventT is initialized with zeros, the same way as in SProcSendEvent. Some event swapping functions do not overwrite all 32 bytes of xEvent structure, for example XSecurityAuthorizationRevoked. Two cooperating clients, one swapped and the other not, can send XSecurityAuthorizationRevoked event to each other to retrieve old stack data from X server. This can be potentialy misused to go around ASLR or stack-protector. Signed-off-by: Michal Srb <msrb@suse.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Xi: Use WarpPointerProc hook on XI pointer warping implementationCarlos Garnacho2017-06-071-0/+4
| | | | | | | | Just like we do with XWarpPointer's. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Add a Meson build system alongside autotools.Eric Anholt2017-04-261-0/+67
| | | | | | | | | | | | | | | | | | This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest, and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but hasn't been built yet. The unit tests are also not done. The intent is to build this as a complete replacement for the autotools system, then eventually replace autotools. meson is faster to generate the build, faster to run the bulid, shorter to write the build files in, and less error-prone than autotools. v2: Fix indentation nits, move version declaration to project(), use existing meson_options for version-config.h's vendor name/web. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Keith Packard <keithp@keithp.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
* dispatch: Mark swapped dispatch as _X_COLDAdam Jackson2017-03-0151-92/+92
| | | | | | | | | This touches everything that ends up in the Xorg binary; the big missing part is GLX since that's all generated code. Cuts about 14k from the binary on amd64. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* Xi: when creating a new master device, update barries for all clientsPeter Hutterer2016-11-301-2/+4
| | | | | | | | | | The previous code only worked when the barrier was created by the same client as the one calling XIChangeDeviceHierarchy. http://bugzilla.redhat.com/show_bug.cgi?id=1384432 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniels@collabora.com>
* xwayland: Don't send KeyRelease events on wl_keyboard::leaveRui Matos2016-11-291-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | Commits 816015648ffe660ddaa0f7d4d192e555b723c372 and fee0827a9a695600765f3d04376fc9babe497401 made it so that wl_keyboard::enter doesn't result in X clients getting KeyPress events while still updating our internal xkb state to be in sync with the host compositor. wl_keyboard::leave needs to be handled in the same way as its semantics from an X client POV should be the same as an X grab getting triggered, i.e. X clients shouldn't get KeyRelease events for keys that are still down at that point. This patch uses LeaveNotify for these events on wl_keyboard::leave and changes the current use of KeymapNotify to EnterNotify instead just to keep some symmetry between both cases. On ProcessDeviceEvent() we still need to deactivate X grabs if needed for KeyReleases. Signed-off-by: Rui Matos <tiagomatos@gmail.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* ddx: add new call to purge input devices that weren't addedPeter Hutterer2016-10-261-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Special case for the systemd-logind case in xfree86: when we're vt-switched away and a device is plugged in, we get a paused fd from logind. Since we can't probe the device or do anything with it, we store that device in the xfree86 and handle it later when we vt-switch back. The device is not added to inputInfo.devices until that time. When the device is removed while still vt-switched away, the the config system never notifies the DDX. It only runs through inputInfo.devices and our device was never added to that. When a device is plugged in, removed, and plugged in again while vt-switched away, we have two entries in the xfree86-specific list that refer to the same device node, both pending for addition later. On VT switch back, the first one (the already removed one) will be added successfully, the second one (the still plugged-in one) fails. Since the fd is correct, the device works until it is removed again. The removed devices' config_info (i.e. the syspath) doesn't match the actual device we addded tough (the input number increases with each plug), it doesn't get removed, the fd remains open and we lose track of the fd count. Plugging the device in again leads to a dead device. Fix this by adding a call to notify the DDX to purge any remainders of devices with the given config_info, that's the only identifiable bit we have at this point. https://bugs.freedesktop.org/show_bug.cgi?id=97928 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
* Hold input lock while calling input device SetProperty callbackKeith Packard2016-09-151-0/+2
| | | | | | | | | This keeps the input driver SetProperty function from being called while input events are being processed. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* xinput: Let top-level dispatch generate the errorAdam Jackson2016-08-161-2/+2
| | | | | | | ... instead of calling SendErrorToClient ourselves. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
View Lorry Controller Status