This was fixed in commit 51eb63b0ee but woefully badly. Instead of returning
XIAlreadyGrabbed via the Reply, it simply returned the value from the
request handler - causing the server to interpret it as BadRequest.
Fix it and do what we intended to do instead.
Fixes: 51eb63b0ee ("Xi: disallow passive grabs with a detail > 255")
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2186>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When the target device is disabled, ProcXIGrabDevice returns
AlreadyGrabbed directly as the request handler return value.
AlreadyGrabbed (1) is a grab status code, not an X error code. The
server dispatch loop interprets any non-zero return value as an X
protocol error, so the client receives BadRequest (error code 1)
instead of a proper XIGrabDevice reply with status=AlreadyGrabbed.
And use XIAlreadyGrabbed since this is an XI2 request. It's the same
value anyway.
This is the same class of bug that was fixed in ProcXIPassiveGrabDevice
by commit 'Xi: Fix XIPassiveGrab handling of keycodes > 255'
Fix by jumping to the reply path with status=AlreadyGrabbed instead of
returning the status code directly.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2186>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
During extension init this makes sense, failing to assign a name to a
new device is more controversial but none of the paths handle
this situation correctly right now so we're just as likely to introduce
an exploit if the name remains NULL.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2184>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Unlikely that those operations ever coming from a remote client,
let alone one with different endianess, but nevertheless let's be
correct here :)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Yet another old Xorg bug: the even masks are transmitted as CARD32's,
so they also need to be byte-swapped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nothing in there that we need, include <regionstr.h> instead.
But keeping the file in place, until all external consumer have
been migrated.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep it in public SDK.
Since it's used by internal modules, still needs to be _X_EXPORT'ed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that all individual swapping request handlers have been merged into the
actual ones, there's no need for a separate dispatcher anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(The existing setting of led_mask is probably wrong, but has been set
like this since X11R5 and going back as far as the first version in
the X Consortium source control archives.)
Reported in https://gitlab.freedesktop.org/xorg/xserver/-/issues/1817:
xwayland-24.1.6/redhat-linux-build/../Xi/getfctl.c:108:9:
warning[-Wanalyzer-use-of-uninitialized-value]:
use of uninitialized value ‘*k2.led_values’
108|-> swapl(&k2->led_values);
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2075>
The wOtherInputMasks(win) macro will return NULL if
win->optional is NULL.
Reported in https://gitlab.freedesktop.org/xorg/xserver/-/issues/1817:
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:1390:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:1404:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:2293:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:3244:22:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘inputMasks’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:3338:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2075>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
iterating over screen list via lambda-esque macros calls like this
DIX_FOR_EACH_SCREEN({
do_something
});
withing the body, the iterator variables `walkScreenIdx` and `walkScreen`
are defined and can be directly used (read-only). the code inside the body
is running in a separate scope.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
CoreEnterLeaveEvent calls FixUpEventFromWindow with a pointer to a stack-allocated xEvent structure, which may get later casted into an xXIDeviceEvent*, with writes done by FixUpXI2DeviceEventFromWindow at an offset larger than sizeof(xEvent). This code-path is protected by xi2_get_type() but the following warning is generated by building with -O3 and LTO:
In function 'FixUpXI2DeviceEventFromWindow',
inlined from 'FixUpEventFromWindow' at ../dix/events.c:2716:13,
inlined from 'CoreEnterLeaveEvent' at ../dix/events.c:4679:5:
../dix/events.c:2628:48: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2628 | ((xXIEnterEvent *) event)->same_screen =
| ^
../dix/events.c: In function 'CoreEnterLeaveEvent':
../dix/events.c:4652:12: note: at offset 48 into destination object 'event' of size 32
4652 | xEvent event = {
| ^
This PR suppresses this warning, by tracking the level of the event (ie., core event, XI or XI2) and ensuring that fix-up is performed only on XI2 events.
Signed-off-by: alex14fr <alex14fr@gmail.com>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, no no need to keep it in public SDK.
Since it's not used by drivers, it's effectively not an ABI change,
so can be done within ABI-25.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't rely on this file just being included indirectly by somebody else
just by accident.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
