Bump to e5e9598.

fix buffer overflow when handling long composed input

To reproduce the issue:

"
If you already have the multi-key enabled on your system, then add this line
to your ~/.XCompose file:

[...]
<question> <T> <E> <S> <T> <question> :
"1234567890123456789012345678901234567890123456789012345678901234567890"
"

Reported by and an initial patch by Andy Gozas <andy@gozas.me>, thanks!

Adapted the patch, for now st (like dmenu) handles a fixed amount of composed
characters, or otherwise ignores it. This is done for simplicity sake.

Ref.
https://git.suckless.org/st/commit/e5e959835b195c023d1f685ef4dbbcfc3b5120b2.html
This commit is contained in:
Bakkeby 2022-10-25 17:21:09 +02:00
parent d8529b66a4
commit e6a2fb489c
2 changed files with 7 additions and 4 deletions

9
x.c
View file

@ -3101,7 +3101,7 @@ void
kpress(XEvent *ev)
{
XKeyEvent *e = &ev->xkey;
KeySym ksym;
KeySym ksym = NoSymbol;
char buf[64], *customkey;
int len, screen;
Rune c;
@ -3136,10 +3136,13 @@ kpress(XEvent *ev)
if (IS_SET(MODE_KBDLOCK))
return;
if (xw.ime.xic)
if (xw.ime.xic) {
len = XmbLookupString(xw.ime.xic, e, buf, sizeof buf, &ksym, &status);
else
if (status == XBufferOverflow)
return;
} else {
len = XLookupString(e, buf, sizeof buf, &ksym, NULL);
}
#if KEYBOARDSELECT_PATCH
if ( IS_SET(MODE_KBDSELECT) ) {
if ( match(XK_NO_MOD, e->state) ||