| Summary: | make -C test/xi2 check fails on sparc and ppc | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Julien Cristau <jcristau> | ||||
| Component: | Server/Input/Core | Assignee: | Xorg Project Team <xorg-team> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | peter.hutterer | ||||
| Version: | 7.5 (2009.10) | ||||||
| Hardware: | SPARC | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Julien Cristau
2009-12-07 10:39:59 UTC
weird. just verified this doesn't happen on my x86 box.
(gdb) p *k
$2 = {type = 0, length = 42, sourceid = 0, num_keycodes = 43}
I don't know how that could happen, it reeks of some other corruption. The matching length field is calculated in appendKeyInfo (dix/eventconvert.c) and it's a simple sizeof(xXIKeyInfo)/4 + num_keycodes. so in this case, length should be 45.
if you find time to valgrind this test, that'd be great. you can run it directly, just execute the protocol-eventconvert binary.
> --- Comment #1 from Peter Hutterer <peter.hutterer@who-t.net> 2009-12-07 17:28:10 PST ---
> if you find time to valgrind this test, that'd be great. you can run it
> directly, just execute the protocol-eventconvert binary.
>
reproduced on powerpc, which does have valgrind. Unfortunately, no
luck, it doesn't seem to find any error.
Created attachment 32246 [details] [review] patch to fix the test I think I understand what happened. Not sure why it doesn't trigger on all platforms though... We run test_XIDeviceChangedEvent(&in); with in.keys.min_keycode = 0 and in.keys.max_keycode = 0xFFFD. In appendKeyInfo(), we set info->num_keycodes to dce->keys.max_keycode - dce->keys.min_keycode + 1 (which is 0xFFFE). And then info->length = sizeof(xXIKeyInfo)/4 + info->num_keycodes is 0, since info->length is u16. appendKeyInfo() returns 0, and the event gets corrupted. Changing the test to set in.keys.max_keycode to 0xFFFC makes it pass. interesting. because appendKeyInfo returns 0, the pointer isn't advanced and the key field is simply overwritten with the next valuator. Because of that and random misc, the next couple of classes are then interpreted as valuator information and I think the reason that it fails on ppc is that some values (garbage) are byte-swapped and trigger the error, where they just happen to be correct on x86. Anyway, patch to trigger failure on x86 is here: http://lists.freedesktop.org/archives/xorg-devel/2009-December/004339.html I've merged your patch, it works. Will be in my next pull request. Both patches are in master now, closing. commit b44c9be244cee286835855483a69c69e80b095c0 Author: Julien Cristau <jcristau@debian.org> Date: Tue Dec 22 17:14:09 2009 +0100 test/xi2: fix maximum max_keycode (bug#25492) The number of keycodes needs to be lower than 0xFFFD so that the length field of xXIKeyInfo doesn't overflow. Signed-off-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> commit 90e6d93cf9bfafd63d7849dc16ce194d6f9c9d5f Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed Dec 23 12:54:14 2009 +1000 test/xi2: fail if xi2 class type is garbage. (#25492) If the keycode range exceeds the allowable length, memory gets overwritten. Catch this case by making sure that only allowed class types are present. X.Org Bug 25492 <http://bugs.freedesktop.org/show_bug.cgi?id=25492> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Keith Packard <keithp@keithp.com> |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.