These sequences are intended for use in the ara(mac-phonetic) and
my(phonetic) layouts. They are based on the following layouts listed in
the CLDR:
- https://github.com/unicode-org/cldr/blob/release-43/keyboards/osx/ar-t-k0-osx-qwerty.xml
- https://github.com/unicode-org/cldr/blob/release-43/keyboards/osx/ms-t-k0-osx.xml
The sequences are listed in the `<transforms>` section, and are
reproduced below:
```
<transforms type="simple">
<transform from="ء\u{64E}" to="آ"/> <!-- ءَ → آ -->
<transform from="ء\u{650}" to="إ"/> <!-- ءِ → إ -->
<transform from="ء " to="ء"/>
<transform from="ء\u{A0}" to="ء"/>
<transform from="ء!" to="إ"/>
<transform from="ء١" to="إ"/>
<transform from="ءا" to="أ"/>
<transform from="ءس" to="ئ"/>
<transform from="ءو" to="ؤ"/>
<transform from="ءي" to="ئ"/>
<transform from="ءى" to="ئ"/>
</transforms>
```
We limit ourselves to the sequences that strictly combine a character
and a hamza, and generate that character with a hamza on it, following
the behavior in sequences of other dead keys. Additional sequences,
potentially for other layouts as well, could be added later on as
necessary.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/218>
When `num_fields == 12`, if the last character of the pattern is '-',
the `buf` array is overrun.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/modules/om/generic/omGeneric.c:691: cond_at_most:
Checking "length > 255" implies that "length" may be up to 255 on
the false branch.
libX11-1.8.7/modules/om/generic/omGeneric.c:695: alias:
Assigning: "last" = "buf + length - 1". "last" may now point to as
high as byte 254 of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:718: ptr_incr:
Incrementing "last". "last" may now point to as high as byte 255
of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:720: ptr_incr:
Incrementing "last". "last" may now point to as high as byte 256
of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:720: overrun-local:
Overrunning array of 256 bytes at byte offset 256 by
dereferencing pointer "++last".
# 718| *++last = '*';
# 719|
# 720|-> *++last = '-';
# 721| break;
# 722| case 13:
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
This error has been found by a static analysis tool. This is the report:
Error: RESOURCE_LEAK (CWE-772):
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1316: alloc_fn:
Storage is returned from allocation function "calloc".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1316: var_assign:
Assigning: "tmp" = storage returned from
"calloc((size_t)((buf_size + data_len == 0) ? 1 : (buf_size + data_len)), 1UL)".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1319: noescape:
Resource "tmp" is not freed or pointed-to in "memcpy".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1320: var_assign:
Assigning: "buf" = "tmp".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1302: var_assign:
Assigning: "data" = "buf".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1303: noescape:
Resource "data" is not freed or pointed-to in
"_XimEncodeIMATTRIBUTE".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "data" going out of scope leaks the storage it points to.
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "buf" going out of scope leaks the storage it points to.
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "tmp" going out of scope leaks the storage it points to.
# 1331|
# 1332| if (!total)
# 1333|-> return (char *)NULL;
# 1334|
# 1335| buf_s = (CARD16 *)&buf[XIM_HEADER_SIZE];
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
Passing a negative value in `needed` to the `XkbResizeKeyActions()`
function can create a `newActs` array of an unespected size.
Check the value and return if it is invalid.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: cond_const:
Checking "xkb->server->size_acts == 0" implies that
"xkb->server->size_acts" is 0 on the true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: buffer_alloc:
"calloc" allocates 8 bytes dictated by parameters
"(size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts)"
and "8UL".
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: var_assign:
Assigning: "newActs" = "calloc((size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts), 8UL)".
libX11-1.8.7/src/xkb/XKBMAlloc.c:815: assignment:
Assigning: "nActs" = "1".
libX11-1.8.7/src/xkb/XKBMAlloc.c:829: cond_at_least:
Checking "nCopy > 0" implies that "nCopy" is at least 1 on the
true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:830: overrun-buffer-arg:
Overrunning buffer pointed to by "&newActs[nActs]" of 8 bytes by
passing it to a function which accesses it at byte offset 15
using argument "nCopy * 8UL" (which evaluates to 8).
# 828|
# 829| if (nCopy > 0)
# 830|-> memcpy(&newActs[nActs], XkbKeyActionsPtr(xkb, i),
# 831| nCopy * sizeof(XkbAction));
# 832| if (nCopy < nKeyActs)
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
In the `res->resource_size == XimType_NEST` code path, if
`res->xrm_name != pre_quark` and `res->xrm_name != sts_quark`, `len` can
be used uninitialized.
This error has been found by a static analysis tool. This is the report:
Error: UNINIT (CWE-457):
libX11-1.8.7/modules/im/ximcp/imRmAttr.c:1106: var_decl:
Declaring variable "len" without initializer.
libX11-1.8.7/modules/im/ximcp/imRmAttr.c:1179: uninit_use:
Using uninitialized value "len".
# 1177| }
# 1178|
# 1179|-> if (len == 0) {
# 1180| continue;
# 1181| } else if (len < 0) {
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
`_XimRead()` is being called with `reply` as target buffer instead of
using `preply`, accessing uninitialized memory a few lines later.
This error has been found by a static analysis tool. This is the report:
Error: UNINIT (CWE-457):
libX11-1.8.7/modules/im/ximcp/imExten.c:468: alloc_fn:
Calling "malloc" which returns uninitialized memory.
libX11-1.8.7/modules/im/ximcp/imExten.c:468: assign:
Assigning: "preply" = "malloc((size_t)((buf_size == 0) ? 1 : buf_size))",
which points to uninitialized data.
libX11-1.8.7/modules/im/ximcp/imExten.c:479: uninit_use:
Using uninitialized value "*((CARD8 *)preply)".
# 477| return False;
# 478| buf_s = (CARD16 *)((char *)preply + XIM_HEADER_SIZE);
# 479|-> if (*((CARD8 *)preply) == XIM_ERROR) {
# 480| _XimProcError(im, 0, (XPointer)&buf_s[3]);
# 481| if(reply != preply)
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
`_XimRead()` is being called with `reply` as target buffer instead of
using `preply`, accessing uninitialized memory a few lines later.
This error has been found by a static analysis tool. This is the report:
Error: UNINIT (CWE-457):
libX11-1.8.7/modules/im/ximcp/imDefLkup.c:561: alloc_fn:
Calling "malloc" which returns uninitialized memory.
libX11-1.8.7/modules/im/ximcp/imDefLkup.c:561: assign:
Assigning: "preply" = "malloc((size_t)((len == 0) ? 1 : len))",
which points to uninitialized data.
libX11-1.8.7/modules/im/ximcp/imDefLkup.c:573: uninit_use:
Using uninitialized value "*((CARD8 *)preply)".
# 571| }
# 572| buf_s = (CARD16 *)((char *)preply + XIM_HEADER_SIZE);
# 573|-> if (*((CARD8 *)preply) == XIM_ERROR) {
# 574| _XimProcError(im, 0, (XPointer)&buf_s[3]);
# 575| if(reply != preply)
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
If an XIM application does not return the XKeyEvent from XNextEvent()
to XFilterEvent(), a timeout is reached and the behavior is fallen
back to the previous one with a warning messsage and we can ask
the application to send the XKeyEvent to XFilterEvent() but also
libX11 provides LIBX11_ENABLE_FABRICATED_ORDER environment variable.
If the application runs with LIBX11_ENABLE_FABRICATED_ORDER=0, the
previous behavior is available until the application is fixed.
Closes: !246
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
When input focuses are switched quickly with shortcut keys in a Java
window, the focus is sometimes lost and the Window=0 is assigned in
XFilterEvent() but the XKeyEvent was forwarded by a XIM serer(IBus)
with XIM_FORWARD_EVENT -> XNextEvent() -> XFilterEvent() and the event
needs to be forwarded to the XIM XKeyEvent press and release filters
to update the XIM state with Window=0 likes _XimPendingFilter() and
_XimUnfabricateSerial().
Closes: #205, #206
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
When users type keys quickly, some applications using Steam or Java
do not call XNextEvent() for a key event but _XimFilterKeypress()
and _XimFilterKeyrelease() expect to receive the key events
forwarded by input methods.
Now fabricated_time Time value is added to XimProtoPrivate to check
the timeout value.
Closes: #205
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
GTK2 applications with GTK_IM_MODULE=xim sets the serial number 0
to the XKeyEvent and the previous _XimFabricateSerial() logic did
not work for the applications.
Now the API marks to fabricate with the serial 0.
Closes: #205
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
Xic.private.proto.commit_info can receive multiple XimCommitInfo
when typing keys very quickly like an bar code scanner (or evemu-play)
and the first info in XimCommitInfo should be committed to keep
the typing key order.
This and 041b5291 are same patches but the regression issues will be
fixed by the later patches.
Closes: #198
Fixes: 041b5291 ("imDefLkup: Commit first info in XimCommitInfo")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
_XimProtoKeypressFilter() and _XimProtoKeyreleaseFilter() can
receive XKeyEvent from both the typing on the keyboard and the
callback of XIM_FORWARD_EVENT.
If the filter functions unmark to fabricate XKeyEvent from the typing
on the keyboard during receiving XKeyEvent from the callback of
XIM_FORWARD_EVENT with typing keys very quickly likes an bar code
scanner (or evemu-play), XIM server cannot receive some key events and
it causes the key typing order to get scrambled.
Now XIM client saves the serial in XKeyEvent and the filter functions
unmark to fabricate XKeyEvent from the callback of XIM_FORWARD_EVENT
only.
This and 024d229f are same patches but the regression issues will be
fixed by the later patches.
Closes: #198
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
I can't find any evidence this was ever defined, should only have
been needed for odd-ball pre-C89 compilers.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Xic.private.proto.commit_info can receive multiple XimCommitInfo
when typing keys very quickly like an bar code scanner (or evemu-play)
and the first info in XimCommitInfo should be committed to keep
the typing key order.
Fixes: #198
_XimProtoKeypressFilter() and _XimProtoKeyreleaseFilter() can
receive XKeyEvent from both the typing on the keyboard and the
callback of XIM_FORWARD_EVENT.
If the filter functions unmark to fabricate XKeyEvent from the typing
on the keyboard during receiving XKeyEvent from the callback of
XIM_FORWARD_EVENT with typing keys very quickly likes an bar code
scanner (or evemu-play), XIM server cannot receive some key events and
it causes the key typing order to get scrambled.
Now XIM client saves the serial in XKeyEvent and the filter functions
unmark to fabricate XKeyEvent from the callback of XIM_FORWARD_EVENT
only.
Fixes: #198
XkbGetDeviceInfo(dpy, XkbXI_ButtonActionsMask, 2, 0, 0) always returns
NULL because the number of buttons on the device equals (unsurpisingly)
the number of buttons requested (i.e. first + nBtns == dev->nbuttons).
This currently causes it to bail out and return NULL.
Fixes f293659d5a
Direct leak of 12 byte(s) in 2 object(s) allocated from:
#0 0x7f4f25c3f7a7 in strdup (/usr/lib64/libasan.so.6+0x5c7a7)
#1 0x7f4f252ce6a1 in _XimEncodeString libX11-1.8.3/modules/im/ximcp/imRm.c:818
#2 0x7f4f252ce6a1 in _XimEncodeString libX11-1.8.3/modules/im/ximcp/imRm.c:807
#3 0x7f4f252d2f0f in _XimSetICValueData libX11-1.8.3/modules/im/ximcp/imRm.c:2912
#4 0x7f4f252b536a in _XimLocalCreateIC libX11-1.8.3/modules/im/ximcp/imLcIc.c:176
#5
0x7f4f251f0105 in XCreateIC libX11-1.8.3/src/xlibi18n/ICWrap.c:251
detected and fix by Patrick Lerda <patrick9876@free.fr>
applied with adjustment, do changes when OOM (unlikely but good practise)
When the format is `Pixmap` it calculates the size of the image data as:
ROUNDUP((bits_per_pixel * width), image->bitmap_pad);
There is no validation on the `width` of the image, and so this
calculation exceeds the capacity of a 4-byte integer, causing an overflow.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The CreatePixmap request specifies height & width of the image as CARD16
(unsigned 16-bit integer), so if either is larger than that, set it to 0
so the X server returns a BadValue error as the protocol requires.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The PutImage request specifies height & width of the image as CARD16
(unsigned 16-bit integer), same as the maximum dimensions of an X11
Drawable, which the image is being copied to.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
When splitting a single line of pixels into chunks to send to the
X server, be sure to take into account the number of bits per pixel,
so we don't just loop forever trying to send more pixels than fit in
the given request size and not breaking them down into a small enough
chunk to fix.
Fixes: "almost complete rewrite" (Dec. 12, 1987) from X11R2
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
