Age | Commit message (Collapse) | Author |
|
|
|
|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
In addition fix FP3232_TO_DOUBLE macro to correctly compute the fractional
part.
This fixes glitchy scrolling in Qt applications when the application was
just activated or was scrolled in the backgroud. Qt uses XIQueryDevice
call to synchronize internal scroll location with an actual one.
Bug: https://gitlab.freedesktop.org/xorg/lib/libxi/issues/10
|
|
When setting up a XIPassiveGrabDevice request, the time field is not
being set, leading to improper data being passed 'over the wire'.
Accept a time value into _XIPassiveGrabDevice and use it to set the time
field in the request. Since the the functions calling
_XIPassiveGrabDevice are part of the API, and they do not accept time
values, they can just pass CurrentTime.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the _XReply() call fails, we'll try to free an uninitialized
pointer.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849026
Reported-by: Thomas Walker <thwalker3@gmail.com>
Signed-off-by: Emilio Pozuelo Monfort <pochu@debian.org>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Tested-by: Thomas Walker <thwalker3@gmail.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
Since we are going to write into the buffer, we should make sure the
allocation didn't fail.
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emilio Pozuelo Monfort <pochu@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Introduced in commit 19a9cd6.
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emilio Pozuelo Monfort <pochu@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
We used to always set *ndevices to the number of devices returned by the
server. This magically worked because we pretty much never returned an error
except on faulty server or library implementations. With 19a9cd60 we now have
more chances of getting an error, so the polite thing is to just leave *ndevices
alone when we error out.
Document it as such in the man page, just in case someone accidentally reads
it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CC: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Catch the error case separately. Commit 19a9cd607d added length checking to
SizeClassInfo but re-used the return value of 0 for an error. A device without
classes (as is initialized by xf86-input-libinput for tablets) can
legitimately return 0 and erroneously triggers an error.
Fix this by using a separate value for the error.
Reproducible by calling XListInputDevices() with a tablet attached.
This fixes a regression introduced in commit 19a9cd607d.
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
By validating length fields from server responses, out of boundary
accesses and endless loops can be mitigated.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
|
|
When invoking Data, Data16 and Data32 from XChangeDeviceProperty,
we must cast the data pointer to the right type, but we do not need
to cast constness away. This change allows to enable -Wcast-qual on
the build and have it complete without warnings.
Signed-off-by: Javier Pello <javier.pello@urjc.es>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
cookie->serial is an Xlib contoction, provided by _XSetLastRequestRead(). This
serial may be different to the raw serial number from the wire protocol.
This causes issues when the raw serial is used to e.g. compare the event to
other non-XI events.
Use the cookie's serial number instead.
https://bugzilla.gnome.org/show_bug.cgi?id=756649
See also https://bugs.freedesktop.org/show_bug.cgi?id=64687
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Commit 5810d0797160a97012664ffe719a59e1b288a525 changed _XIAllowEvents() to
use _XiCheckVersion() instead of _XiCheckExtInit() to avoid a double display
unlock, but it failed to correctly check for the version, since we should set
have_XI22 to True for every version greater or equal to 2.2.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
_XiGetExtensionVersion was called from XGetExtensionVersion and from
_XiCheckExtInit. When called from _XiCheckExtInit, nothing accounted for the
fact that it can return ((XExtensionVersion *) NoSuchExtension) in case of
error. Also it recursively calls _XiCheckExtInit potentionally causing multiple
unlocks if _XiCheckExtInit fails.
-> Remove it and call directly _XiGetExtensionVersionRequest and only call
_XiCheckExtInit only from XGetExtensionVersion.
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Replacing the second _XiCheckExtInit with _XiCheckVersion prevents possible
double unlock as _XiCheckExtInit actually unlocks the display when it returns
-1.
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Not NoSuchExtension which is 1 = True!
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Several functions were returning NoSuchExtension casted to a pointer in case of
an error. Often in parallel with returning NULL in case of another error. It is
undocumented and certainly wrong.
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
When num_changes <= 0 or Xmalloc fails, the display has to be unlocked.
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
_XiCheckExtInit unlocks the display if it fails and returns -1. Most callers
account for it properly, but few didn't.
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
c->length is in 4-byte units, dptr is a char *, so we need to advance
dptr by 4 * length to get the position of the next HierarchyChangeInfo.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
Fix two places where the display was double locked when an API
function chained to an implementation that also locks the display.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
_XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
means that it expects the display to be unlocked. XIGrabTouchBegin locks
the display to check for the XI extension, and then never unlocks it.
Effectively, this meant that anybody that called XIGrabTouchBegin after
XInitThreads just got a deadlock.
Cool.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The code here before would just leave the display locked on error, which is
all sorts of broken.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
_XEatDataWords was orignally introduced with the May 2013 security
patches, and in order to ease the process of delivering those,
fallback versions of _XEatDataWords were included in the X extension
library patches so they could be applied to older versions that didn't
have libX11 1.6 yet. Now that we're past that hurdle, we can drop
the fallbacks and just require libX11 1.6 for building new versions
of the extension libraries.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
clang warns:
warning: comparison of constant 268435455 with expression of type
'CARD16' (aka 'unsigned short') is always false
Signed-off-by: Thomas Klausner <wiz@NetBSD.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Introduced in 4c8e9bcab459ea5f870d3e56eff15f931807f9b7.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If we skip over the reply data, return 0 as number of event classes.
Follow-up to 6dd6dc51a2935c72774be81e5cc2ba2c30e9feff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
size += blah is technically correct but it implies that we're looping or
otherwise incrementing the size. Which we don't, it's only ever set once.
Change this to avoid reviewer confusion.
Reported-by: Dave "color-me-confused" Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
First: check for allocation failure on the mask.
XI2 requires that the mask is zeroed, so we can't just Data() the mask
provided by the client (it will pad) - we need a tmp buffer. Make sure that
doesn't fail.
Second:
req->mask_len is a uint16_t, so check against malicious mask_lens that would
cause us to corrupt memory on copy, as the code always allocates
req->mask_len * 4, but copies mask->mask_len bytes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
serial != sequenceNumber, see _XSetLastRequestRead()
cookie->serial is already set at this point, setting it again directly from
the sequenceNumber of the event causes a bunch of weird issues such as
scrollbars and text drag-n-drop breaking.
https://bugzilla.redhat.com/show_bug.cgi?id=965347
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
nptr is (signed) char, which can be negative, and will sign extend
when added to the int size, which means size can be subtracted from,
leading to allocating too small a buffer to hold the data being copied
from the X server's reply.
v2: check that string size fits inside the data read from the server,
so that we don't read out of bounds either
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the length of the reply as reported by the Xserver is too long, it
could overflow the calculation for the size of the buffer to copy the
reply into, causing memory corruption.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the number of items as reported by the Xserver is too large, it
could overflow the calculation for the size of the buffer to copy the
reply into, causing memory corruption.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the number of events or masks reported by the server is large enough
that it overflows when multiplied by the size of the appropriate struct,
or the sizes overflow as they are totaled up, then memory corruption can
occur when more bytes are copied from the X server reply than the size
of the buffer we allocated to hold them.
v2: check that reply size fits inside the data read from the server,
so that we don't read out of bounds either
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the number of items reported by the server is large enough that
it overflows when multiplied by the size of the appropriate item type,
then memory corruption can occur when more bytes are copied from the
X server reply than the size of the buffer we allocated to hold them.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the number of events or axes reported by the server is large enough
that it overflows when multiplied by the size of the appropriate struct,
then memory corruption can occur when more bytes are copied from the
X server reply than the size of the buffer we allocated to hold them.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the number of event classes reported by the server is large enough
that it overflows when multiplied by the size of the appropriate struct,
then memory corruption can occur when more bytes are copied from the
X server reply than the size of the buffer we allocated to hold them.
V2: EatData if count is 0 but length is > 0 to avoid XIOErrors
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the number of feedbacks reported by the server is large enough that
it overflows when multiplied by the size of the appropriate struct, or
if the total size of all the feedback structures overflows when added
together, then memory corruption can occur when more bytes are copied from
the X server reply than the size of the buffer we allocated to hold them.
v2: check that reply size fits inside the data read from the server, so
we don't read out of bounds either
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the number of valuators reported by the server is large enough that
it overflows when multiplied by the size of the appropriate struct, then
memory corruption can occur when more bytes are copied from the X server
reply than the size of the buffer we allocated to hold them.
v2: check that reply size fits inside the data read from the server, so
we don't read out of bounds either
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the lengths given for each class state in the reply add up to more
than the rep.length, we could read past the end of the buffer allocated
to hold the data read from the server.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If the server returned more modifiers than the caller asked for,
we'd just keep copying past the end of the array provided by the
caller, writing over who-knows-what happened to be there.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
We copy the entire reply sent by the server into the fixed size
mapping[] array on the stack, even if the server says it's a larger
size than the mapping array can hold. HULK SMASH STACK!
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
rep.length is a CARD32, so rep.length << 2 could overflow in 32-bit builds
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
X.Org Bug 64687 <http://bugs.freedesktop.org/show_bug.cgi?id=64687>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
|
|
Unpacking from the wire involves un-interleaving the structs & masks,
which wasn't obvious to me the first time I read it, so make notes
before I forget again.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The PointerBarrier typedef is duplicate if a client includes both Xfixes.h
and XInput2.h.
gcc 4.6 won't complain about that, but earlier versions do:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ce3765bf44e49ef0568a1ad4a0b7f807591d6412
gcc 4.6 with -pedantic-errors shows:
/opt/xorg/include/X11/extensions/XInput2.h:172:13: error: redefinition of
typedef ‘PointerBarrier’ [-pedantic]
In file included from test.c:1:0:
/opt/xorg/include/X11/extensions/Xfixes.h:255:13: note: previous declaration
of ‘PointerBarrier’ was here
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
|
|
Looks like XI_RawTouch* events are missing in the big switch in this function.
When running XIT tests for multitouch devices, several following errors appears:
XInputCopyCookie: Failed to copy evtype 22
XInputCopyCookie: Failed to copy evtype 23
XInputCopyCookie: Failed to copy evtype 24
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|