The XkbCompatMap structure stores its "num_si" and "size_si" fields
using an unsigned short.
However, the function _XkbSetCompatMap() will store the sum of the
input data "firstSI" and "nSI" in both XkbCompatMap's "num_si" and
"size_si" without first checking if the sum overflows the maximum
unsigned short value, leading to a possible overflow.
To avoid the issue, check whether the sum does not exceed the maximum
unsigned short value, or return a "BadValue" error otherwise.
CVE-2025-62231, ZDI-CAN-27560
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2086>
XkbRemoveResourceClient() would free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
gets called and accesses already freed memory:
| Invalid read of size 8
| at 0x5BC0C0: XkbRemoveResourceClient (xkbEvents.c:1047)
| by 0x5B3391: XkbClientGone (xkb.c:7094)
| by 0x4DF138: doFreeResource (resource.c:890)
| by 0x4DFB50: FreeClientResources (resource.c:1156)
| by 0x4A9A59: CloseDownClient (dispatch.c:3550)
| by 0x5E0A53: ClientReady (connection.c:601)
| by 0x5E4FEF: ospoll_wait (ospoll.c:657)
| by 0x5DC834: WaitForSomething (WaitFor.c:206)
| by 0x4A1BA5: Dispatch (dispatch.c:491)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
| Address 0x1893e278 is 184 bytes inside a block of size 928 free'd
| at 0x4842E43: free (vg_replace_malloc.c:989)
| by 0x49C1A6: CloseDevice (devices.c:1067)
| by 0x49C522: CloseOneDevice (devices.c:1193)
| by 0x49C6E4: RemoveDevice (devices.c:1244)
| by 0x5873D4: remove_master (xichangehierarchy.c:348)
| by 0x587921: ProcXIChangeHierarchy (xichangehierarchy.c:504)
| by 0x579BF1: ProcIDispatch (extinit.c:390)
| by 0x4A1D85: Dispatch (dispatch.c:551)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
| Block was alloc'd at
| at 0x48473F3: calloc (vg_replace_malloc.c:1675)
| by 0x49A118: AddInputDevice (devices.c:262)
| by 0x4A0E58: AllocDevicePair (devices.c:2846)
| by 0x5866EE: add_master (xichangehierarchy.c:153)
| by 0x5878C2: ProcXIChangeHierarchy (xichangehierarchy.c:493)
| by 0x579BF1: ProcIDispatch (extinit.c:390)
| by 0x4A1D85: Dispatch (dispatch.c:551)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
To avoid that issue, make sure to free the resources when freeing the
device XkbInterest data.
CVE-2025-62230, ZDI-CAN-27545
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2086>
Currently, the resource in only available to the xkb.c source file.
In preparation for the next commit, to be able to free the resources
from XkbRemoveResourceClient(), make that variable private instead.
This is related to:
CVE-2025-62230, ZDI-CAN-27545
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2086>
The freeRules parameter is always set to TRUE, meaning always free the
XkbRF_RulesRec struct. Therefore also no need to clear out fields that
aren't going to be reused again, ever.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1840>
Allow the compiler to figure out the most efficient way to do the
struct initialization, and a little improvement on code readability.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1840>
The function is nothing more than a calloc() call, so we can spare
an actual function call here by making it static inline.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1840>
Handles common case of allocating & copying string to temporary buffer
(cherry picked from xorg/lib/libxkbfile@8a91517ca6ea77633476595b0eb5b213357c60e5)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
Fixes formatting of negative numbers, so they don't show minus sign
after the decimal point.
(cherry picked from xorg/lib/libxkbfile@d2ec504fec2550f4fd046e801b34317ef4a4bab9)
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
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)
(cherry picked from xorg/lib/libx11@af1312d2873d2ce49b18708a5029895aed477392)
Signed-off-by: José Expósito <jexposit@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
If there was a previous radio_groups array which we failed to realloc
and freed instead, clear the array size in the XkbNamesRec.
Taken from xorg/lib/libx11@258a8ced681dc1bc50396be7439fce23f9807e2a
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1821>
If XkbChangeTypesOfKey() is called with nGroups == 0, it will resize the
key syms to 0 but leave the key actions unchanged.
If later, the same function is called with a non-zero value for nGroups,
this will cause a buffer overflow because the key actions are of the wrong
size.
To avoid the issue, make sure to resize both the key syms and key actions
when nGroups is 0.
CVE-2025-26597, ZDI-CAN-25683
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
The computation of the length in XkbSizeKeySyms() differs from what is
actually written in XkbWriteKeySyms(), leading to a heap overflow.
Fix the calculation in XkbSizeKeySyms() to match what kbWriteKeySyms()
does.
CVE-2025-26596, ZDI-CAN-25543
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
The code in XkbVModMaskText() allocates a fixed sized buffer on the
stack and copies the virtual mod name.
There's actually two issues in the code that can lead to a buffer
overflow.
First, the bound check mixes pointers and integers using misplaced
parenthesis, defeating the bound check.
But even though, if the check fails, the data is still copied, so the
stack overflow will occur regardless.
Change the logic to skip the copy entirely if the bound check fails.
CVE-2025-26595, ZDI-CAN-25545
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
