[Pkg-kbd-devel] Bug#500116: Bug#500116: loadkeys segfaults when dealing with certain Unicode characters

[Michael Schutte]

Colin,

First of all, I’ve been pretty busy lately, so please excuse me for
taking so long to reply.

On Thu, Sep 25, 2008 at 10:06:30AM +0100, Colin Watson wrote:
> 'loadkeys -mu' crashes when given the attached pk.kmap file (generated
> by ckbcomp from console-setup). This is because it XORs the keysym
> "+U+fe7c" with 0xF000 (as it does with all Unicode characters) and gets
> a code with KTYP(code) == 14 == KT_BRL and KVAL(code) == 124. KT_BRL
> obviously has nothing to do with the Arabic Presentation Forms-B range
> containing U+FE7C, but 124 is significantly larger than the size of
> brl_syms. codetoksym fails to bounds-check KVAL(code) and thus
> segfaults.

The mess seems to at least partly originate in a Debian-specific patch
called read_keymaps_fmt [1].  Some testing shows that our “loadkeys -m”
(not only, but it is the easiest way to check) differs significantly
from upstream’s in some cases, not always in ways that look intended.
I’m going to investigate this further as soon as I can.

[1] http://git.debian.org/?p=pkg-kbd/kbd.git;a=commit;h=1c843ea

> I've attached a patch which fixes the segfault by adding
> bounds-checking. I think this is a clear improvement over what's there
> now. However, it still isn't quite perfect, as there are still clashes
> between valid Unicode characters and special keysyms. For instance,
> U+FC00 ARABIC LIGATURE YEH WITH HAMZA ABOVE WITH JEEM ISOLATED FORM
> (never mind that you probably have only about a snowball's chance in
> hell of that working on the Linux console ...) comes out as KTYP(code)
> == 12 == KT_SLOCK and KVAL(code) == 0, so will be interpreted as SShift.

Thanks for the patch; I’ve imported it into the Git repo for now.
Still, I’d rather have a deeper look and really fix the problem at its
root.

> If all of the fake codes were within Unicode's private use range
> E000-F8FF, then I think this would work much better. It seems that this
> would just involve XORing with 0xE000 rather than 0xF000. However, I
> know that the Linux consolemap code interprets 0xF000-0xF0FF as
> "transparent Unicode" that gets mapped directly to font positions, and
> I'm not sure whether kbd relies on this, so I didn't want to just
> crudely substitute 0xE000 for 0xF000 across the board. I'd appreciate
> your advice here.

This might just work, but I’m not sure I like the idea.  I hope, no—I’m
sure there are more elegant solutions :-)

Cheers,
-- 
Michael Schutte <michi at uiae.at>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-kbd-devel/attachments/20081022/3783ea52/attachment.pgp