libudev1 seems to cause a segfault in pcscd when a Vasco DP905v1.1 smart card reader is inserted before pcscd is started

[Wouter Verhelst]

Hi,

When one plugs in a Vasco DP905v1.1 smart card reader before pcscd is started and waits for a few moments, the green 'power' led on this device will go off, indicating that the device is in low-power mode. When this happens, due to an issue with the specific card reader model, it seems to be impossible to revive the card reader without power-cycling the USB bus.

This is especially annoying as the time between 'USB bus receives power' and 'pcscd starts' is longer than the time it takes for the DP905v1.1 to go to low-power mode on many systems, causing loss of functionality for people who leave their smart card reader plugged in at boot time, and a segfault when the most obvious way to fix the issue (remove the card reader from the USB bus and plug it in again) is attempted. While the loss of functionality could be considered a bug in the smart card reader, not necessarily libudev's problem, the segfault is a different matter.

When one then starts pcscd with the '-f' option (for 'foreground'), the following information is printed to the console:

00000000 ccid_usb.c:790:ReadUSB() read failed (2/6): -7 Resource temporarily unavailable
05000798 ccid_usb.c:751:WriteUSB() write failed (2/6): -7 Resource temporarily unavailable
05000403 ccid_usb.c:751:WriteUSB() write failed (2/6): -7 Resource temporarily unavailable
00000027 ifdhandler.c:158:CreateChannelByNameOrChannel() failed
00000021 readerfactory.c:1020:RFInitializeReader() Open Port 0x200000 Failed (usb:1a44/0001:libudev:0:/dev/bus/usb/002/006)
00000009 readerfactory.c:312:RFAddReader() VASCO DP905v1.1 init failed.
00000126 hotplug_libudev.c:391:HPAddDevice() Failed adding USB device: VASCO DP905v1.1

At this point pcscd is stuck waiting, and removing the card reader causes the segfault.

I installed a few debug symbols packages and recompiled pcscd with DEB_BUILD_OPTIONS=nostrip in an effort to figure out some more information, and have found the following:

At the point when the segfault happens, pcscd will have three threads running:
- The first thread is the main thread, which is usually in select()
- The second thread seems to be a helper thread of some sort; its stack backtrace contains no function symbols
- The third thread will always be in pcscd:hotplug_libudev.c, line 433:

  udev_enumerate_scan_devices(enumerate);

  going down the stack trace into libudev gets us:

#0 0x00007ffff72c5200 in __openat_nocancel (fd=-100,
    file=0x7ffff5d228d0 "/sys/bus", oflag=591872, mode=0)
    at ../sysdeps/unix/sysv/linux/wordsize-64/../openat.c:93
#1 0x00007ffff7296935 in __opendirat (dfd=dfd@entry=-100,
    name=name@entry=0x7ffff5d228d0 "/sys/bus")
    at ../sysdeps/posix/opendir.c:129
#2 0x00007ffff729697d in __opendir (name=name@entry=0x7ffff5d228d0 "/sys/bus")
    at ../sysdeps/posix/opendir.c:160
#3 0x00007ffff7bd0a02 in scan_dir (
    udev_enumerate=udev_enumerate@entry=0x7ffff0001670,
    basedir=basedir@entry=0x7ffff7bd4d11 "bus",
    subdir=subdir@entry=0x7ffff7bd4d09 "devices",
    subsystem=subsystem@entry=0x0) at ../src/libudev/libudev-enumerate.c:742
#4 0x00007ffff7bd1280 in scan_devices_all (udev_enumerate=0x7ffff0001670)
    at ../src/libudev/libudev-enumerate.c:893
#5 udev_enumerate_scan_devices (
    udev_enumerate=udev_enumerate@entry=0x7ffff0001670)
    at ../src/libudev/libudev-enumerate.c:922
#6 0x000000000040e2d9 in HPRescanUsbBus (udev=udev@entry=0x629cb0)
    at hotplug_libudev.c:433
#7 0x000000000040e761 in HPEstablishUSBNotifications (udev=0x629cb0)
    at hotplug_libudev.c:595
#8 0x00007ffff75a7182 in start_thread (arg=0x7ffff5d23700)
    at pthread_create.c:312
#9 0x00007ffff72d3fbd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Although this thread is always at the same location which makes me think it seems to cause the segfault, I should note that it is in fact the second thread which does so:

(gdb) thread 2
[Switching to thread 2 (Thread 4168)]
#0 0x00007ffff6533248 in ?? ()
(gdb) where
#0 0x00007ffff6533248 in ?? ()
#1 0x00007ffff6524700 in ?? ()
#2 0x0000000000000018 in ?? ()
#3 0x0000000100000005 in ?? ()
#4 0x0001000100000004 in ?? ()
#5 0x00007ffff6524700 in ?? ()
#6 0x00007ffff6524700 in ?? ()
#7 0x0000000000000000 in ?? ()

but as said, I'm not sure what to do with this.

After having figured out that it's somewhere inside libudev, I wanted to file a bug with a crash report, but apparently I must've done something wrong, because apport no longer seems to want to write crash reports on this system. To make matters worse, I also can't create a core dump using 'ulimit -c unlimited'. If someone could help me fix that, I'll happily submit a core dump if needed.

This problem has been observed on at least three machines, all running trusty (some amd64, some i386).

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: libudev1 204-5ubuntu20.5
ProcVersionSignature: Ubuntu 3.13.0-35.62-generic 3.13.11.6
Uname: Linux 3.13.0-35-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.3
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Sep 8 12:21:43 2014
InstallationDate: Installed on 2014-08-28 (11 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.