From 72036644746c47a09eec106c367f186713fd606d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 20 Apr 2026 11:17:41 +1000 Subject: [PATCH] xkb: reject key types with num_levels exceeding XkbMaxShiftLevel CheckKeyTypes validates incoming key type definitions from XkbSetMap requests but does not enforce an upper bound on numLevels. A client can set numLevels up to 255 on a non-canonical key type, which is stored in the server's type table. When ChangeKeyboardMapping later triggers XkbUpdateKeyTypesFromCore, the function XkbKeyTypesForCoreSymbols computes groupsWidth from num_levels and uses the XKB_OFFSET(g, l) = (g * groupsWidth) + l macro to index into tsyms[], a stack-allocated buffer of XkbMaxSymsPerKey (252) entries. With num_levels=255, groupsWidth=255, and indices reach up to 3*255+254 = 1019, overflowing the 252-element stack buffer by 767 KeySym-sized entries. Fix by rejecting numLevels values greater than XkbMaxShiftLevel (63) in CheckKeyTypes, alongside the existing lower-bound check for numLevels < 1. This vulnerability was discovered by: Anonymous working with TrendAI Zero Day Initiative ZDI-CAN-30160 Assisted-by: Claude:claude-opus-4-6 (cherry picked from commit 543e108516428fc8c3bea91d6563ad266f9a801e) Part-of: --- xkb/xkb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xkb/xkb.c b/xkb/xkb.c index c389448e4..b5d601dcb 100644 --- a/xkb/xkb.c +++ b/xkb/xkb.c @@ -1647,7 +1647,7 @@ CheckKeyTypes(ClientPtr client, } n = i + req->firstType; width = wire->numLevels; - if (width < 1) { + if (width < 1 || width > XkbMaxShiftLevel) { *nMapsRtrn = _XkbErrCode3(0x04, n, width); return 0; }