When every key in a keymap has zero groups, ctrls->num_groups is 0 and each out-of-range action here misbehaves.
XkbWrapIntoRange divides by zero, which is the reported crash. XkbClampIntoRange is worse: it computes -1,
returns it through this function's unsigned type, and the callers truncate it into XkbStateRec's unsigned char
group fields as 255, after which XkbComputeCompatState() reads map->groups[255] out of a four element array and
reports what it finds to clients in the compat state of every core event. The negative-group case adds zero
forever, wedging the server thread, in one path while it holds input_lock. XkbComputeDerivedState() treats group
0 as out of range once num_groups is 0, so all of this is reachable from an ordinary key event.
XQuartz gets there because it asks for model "empty", whose keycodes file declares no key names, so a keymap
compiled at a client's request has no key definitions at all.
Guard the arithmetic itself and not just the places that compute num_groups: groups_wrap selects between these
actions and is client settable, and this is exported for DDXes that supply their own controls.
Fixes: https://github.com/XQuartz/XQuartz/issues/422
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2278>
(cherry picked from commit bdb14dce4b)
(cherry picked from commit b5ea5591d1f514d0eb0cc5f58052a24fd1b06b9e)
(cherry picked from commit eb420bff03b4ae05d00821482c9fcfaf32a2922d)
d8cee7e08b