xkbLEDs causes segfault on login

Bug #180884 reported by Justin Dugger
10
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Critical
xorg-server (Ubuntu)
Undecided
Unassigned

Bug Description

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.

Revision history for this message
Justin Dugger (jldugger) wrote :

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}

Revision history for this message
In , Justin Dugger (jldugger) wrote :

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.

Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

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.

Revision history for this message
In , Justin Dugger (jldugger) wrote :

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.

Revision history for this message
In , Justin Dugger (jldugger) wrote :

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!

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

(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))

Revision history for this message
Bryce Harrington (bryce) wrote :

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.

Changed in xorg-server:
status: New → Incomplete
Revision history for this message
Justin Dugger (jldugger) wrote :

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.

Revision history for this message
Justin Dugger (jldugger) wrote :

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

Revision history for this message
Justin Dugger (jldugger) wrote :

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))

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

ping?

Revision history for this message
In , Justin Dugger (jldugger) wrote :

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.

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

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

pushed as d954f9c80348de294602d931d387e5cd1ef4b9a5

Revision history for this message
In , Justin Dugger (jldugger) wrote :

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

Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

(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

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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

Changed in xorg-server:
status: Incomplete → Fix Released
Changed in xorg-server:
importance: Unknown → Critical
Changed in xorg-server:
importance: Critical → Unknown
Changed in xorg-server:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.