Description of problem:

After a while, the pcscd daemon causes high CPU load and then randomly crashes. First time I noticed the high load after about an half an hour. The second time, the load went up and I the daemon crashed before I started investigating what could be wrong.

This problem appeared after upgrading to Fedora 24.

The following log entries look related:

Apr 25 13:19:11 basbombardon pcscd[10460]: 99999999 commands.c:1094:CmdPowerOff Card absent or mute
Apr 25 13:19:12 basbombardon audit[10465]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:pcscd_t:s0 pid=10465 comm="pcscd" exe="/usr/sbin/pcscd" sig=11
Apr 25 13:19:12 basbombardon kernel: show_signal_msg: 153 callbacks suppressed
Apr 25 13:19:12 basbombardon kernel: pcscd[10465]: segfault at 7f2e7da229f1 ip 00007f2e7da229f1 sp 00007f2e7da11d90 error 14 in libgpg-error.so.0.17.0[7f2e7de48000+14000]
Apr 25 13:19:12 basbombardon systemd[1]: pcscd.service: Main process exited, code=killed, status=11/SEGV
Apr 25 13:19:12 basbombardon systemd[1]: pcscd.service: Unit entered failed state.

When the daemon was spinning the CPU, the strace indicated that the daemon was looping on the poll() call. I guess the poll() result handling in the daemon is incorrect:

[pid 10465] recvmsg(11, 0x7f2e7da0fc50, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 10465] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1 ([{fd=5, revents=POLLIN}])
[pid 10465] recvmsg(11, 0x7f2e7da0fc50, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 10465] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1 ([{fd=5, revents=POLLIN}])
[pid 10465] recvmsg(11, 0x7f2e7da0fc50, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 10465] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1 ([{fd=5, revents=POLLIN}])
...


How reproducible:
always


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

I use opensc PKCS #11 module in ssh-agent for authentication using Yubikey. It might be related. The token session was opened always when this problem appeared.