xkbLEDs causes segfault on login

[Justin Dugger]

Logging into GNOME from GDM with my user causes X.org to segfault. This doesn't happen with a new user, just the old one. I've narrowed it down to a null pointer deref in xkbLEDs.c:67, but I'm not sure how to fix it.

[Justin Dugger (jldugger)]

Program received signal SIGSEGV, Segmentation fault.
XkbIndicatorsToUpdate (dev=0x823f660, state_changes=7945, enable_changes=0)
    at ../../xkb/xkbLEDs.c:67
67 ../../xkb/xkbLEDs.c: No such file or directory.
        in ../../xkb/xkbLEDs.c
(gdb) backtrace full
#0 XkbIndicatorsToUpdate (dev=0x823f660, state_changes=7945, enable_changes=0)
    at ../../xkb/xkbLEDs.c:67
        update = 0
        sli = (XkbSrvLedInfoPtr) 0x0
#1 0x0818bc0d in ProcXkbLatchLockState (client=0x84c2888)
    at ../../xkb/xkb.c:587
        status = <value optimized out>
        dev = (DeviceIntPtr) 0x822b7d8
        tmpd = (DeviceIntPtr) 0x823f660
        oldState = {group = 0 '\0', locked_group = 0 '\0', base_group = 0,
  latched_group = 0, mods = 0 '\0', base_mods = 0 '\0', latched_mods = 0 '\0',
  locked_mods = 0 '\0', compat_state = 0 '\0', grab_mods = 0 '\0',
  compat_grab_mods = 0 '\0', lookup_mods = 0 '\0',
  compat_lookup_mods = 0 '\0', ptr_buttons = 0}
        changed = 0
        sn = {type = 94 '^', xkbType = 2 '\002', sequenceNumber = 340,
  time = 2775041, deviceID = 0 '\0', mods = 16 '\020', baseMods = 0 '\0',
  latchedMods = 0 '\0', lockedMods = 16 '\020', group = 0 '\0', baseGroup = 0,
  latchedGroup = 0, lockedGroup = 0 '\0', compatState = 16 '\020',
  grabMods = 16 '\020', compatGrabMods = 16 '\020', lookupMods = 16 '\020',
  compatLookupMods = 16 '\020', ptrBtnState = 0, changed = 7945,
  keycode = 0 '\0', eventType = 0 '\0', requestMajor = 147 '\223',
  requestMinor = 5 '\005'}
        cause = {kc = 0 '\0', event = 0 '\0', mjr = 147 '\223',
  mnr = 5 '\005', client = 0x84c2888}
#2 0x0818c28d in ProcXkbDispatch (client=0x0) at ../../xkb/xkb.c:6142
No locals.
#3 0x0814ff3e in XaceCatchExtProc (client=0x84c2888) at ../../Xext/xace.c:299
        major = 147
        ext = <value optimized out>
#4 0x0808d8ff in Dispatch () at ../../dix/dispatch.c:502
        result = <value optimized out>
        client = (ClientPtr) 0x84c2888
        nready = 0
        start_tick = 3700
#5 0x0807476b in main (argc=10, argv=0xbfd262b4, envp=0x0)
    at ../../dix/main.c:452
        pScreen = <value optimized out>
        i = 1
        error = 136164272
        xauthfile = <value optimized out>
        alwaysCheckForInput = {0, 1}

[Justin Dugger (jldugger)]

Logging into GNOME from GDM with my user causes X.org to segfault. This doesn't happen with a new user, just the old one. I've narrowed it down to a null pointer deref in xkbLEDs.c:67, but I'm not sure how to best fix it.

I've also reported with Ubuntu hardy, and a stack trace is available: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/180884

Please let me know if any more information is needed to solve this.

[Peter Hutterer (peter-hutterer)]

can you please post your configuration file? the input devices are of interest here.

the other thing that'd be interesting is if you can reproduce the crash in gdb, print out dev->name. this way we know which device causes the problem.

[Justin Dugger (jldugger)]

Created an attachment (id=13786)
configuration for my Toshiba Tecra M7 tablet

The wacom devices are present and working, and are the only nonstandard device I can think of.

[Justin Dugger (jldugger)]

After a bit of wrestling, I got xorg to debug again. The device is "eraser". Naturally, eraser has no LEDs, as it's part of a passive pen device!

[Peter Hutterer (peter-hutterer)]

(In reply to comment #3)
> After a bit of wrestling, I got xorg to debug again. The device is "eraser".
> Naturally, eraser has no LEDs, as it's part of a passive pen device!
>

please try the simple patch below. i think the correct fix would be in the caller but i don't know enough about XKB for that.

diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index 2877af0..55ce12a 100644
--- a/xkb/xkbLEDs.c
+++ b/xkb/xkbLEDs.c
@@ -63,6 +63,9 @@ XkbSrvLedInfoPtr sli;

     sli= XkbFindSrvLedInfo(dev,XkbDfltXIClass,XkbDfltXIId,0);

+ if (!sli)
+ return update;
+
     if (state_changes&(XkbModifierStateMask|XkbGroupStateMask))
  update|= sli->usesEffective;
     if (state_changes&(XkbModifierBaseMask|XkbGroupBaseMask))

[Bryce Harrington (bryce)]

What version of xorg-server are you experiencing this bug with? Please attach your /var/log/Xorg.0.log and /etc/X11/xorg.conf files.

[Justin Dugger (jldugger)]

I've narrowed down the bug to wacom device "erasor" with a bit of help upstream. There's a suggested patch on their tracker which seems harmless enough -- I don't know the callers to that function, but it's clear that its possible to get a null pointer back and something should be done there to avoid a segfault.

[Justin Dugger (jldugger)]

This is with the latest version I can get from hardy. Gutsy is not affected by this.

[Justin Dugger (jldugger)]

Here's the entirety of the patch -- very simple check for a null pointer.
In a duplicate bug, Justin Lynn suggests that linux wacom is fixed upstream to not cause this condition.

diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index 2877af0..55ce12a 100644
--- a/xkb/xkbLEDs.c
+++ b/xkb/xkbLEDs.c
@@ -63,6 +63,9 @@ XkbSrvLedInfoPtr sli;

     sli= XkbFindSrvLedInfo(dev,XkbDfltXIClass,XkbDfltXIId,0);

+ if (!sli)
+ return update;
+
     if (state_changes&(XkbModifierStateMask|XkbGroupStateMask))
        update|= sli->usesEffective;
     if (state_changes&(XkbModifierBaseMask|XkbGroupBaseMask))

[Peter Hutterer (peter-hutterer)]

ping?

[Justin Dugger (jldugger)]

After doing a bit more research, I've discovered reports in Debian's BugTracker that the latest wacom-tools doesn't trigger this. I'm now contemplating how to best go with this. It seems like there are cases where NULL can be received, so your patch is at least a step in the right direction for xkb. I'll see about perhaps building with the patch for Ubuntu (my testing system), but it'll probably take some time. If wacom-tools genuinely fixes the bug, then it's probably a good idea to lower the priority of this bug.

[Peter Hutterer (peter-hutterer)]

actually tracking down this problem is more of a nightmare than fixing the symptom.

pushed as d954f9c80348de294602d931d387e5cd1ef4b9a5

[Justin Dugger (jldugger)]

Any chance that this patch can also be pushed into the 1.4-branch?

[Peter Hutterer (peter-hutterer)]

(In reply to comment #8)
> Any chance that this patch can also be pushed into the 1.4-branch?
>

done. daniels pushed it as bc72ef3a159efd67067322c043bba444869dc356

[Timo Aaltonen (tjaalton)]

This is now fixed in hardy (xorg-server 2:1.4.1~git20080131-1ubuntu1).