Bug 674612 - segfault in pcscd while removing usb during transaction
Summary: segfault in pcscd while removing usb during transaction
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: pcsc-lite
Version: 19
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Bob Relyea
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-02 16:15 UTC by Alon Levy
Modified: 2015-02-17 13:36 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 13:36:10 UTC
Type: ---


Attachments (Terms of Use)

Description Alon Levy 2011-02-02 16:15:46 UTC
Description of problem:
I start a transaction of APDU's using pcscd, pull out the usb reader cable in the middle, and receive the segmentation fault in the Additional info.

The client I'm using is libcacard's vscclient, but I'm not using the packaged one, but the one from libcacard git. Also, libcacard is relatively new, so even if it was the package's wouldn't mean much. Of course this is just background - the segmentation fault is in pcscd, vscclient is just using the API it exposes.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. using a CCID reader (Athena ASE IIIe [ASEDrive CCID] 00 00)
2. using libcacard's vscclient, do some transactions with the card (started
from esc inside linux guest running on qemu with ccid device)
3. pull out plug in the middle of APDU (i.e. there are additional APDU's being
sent to pcscd after the usb is removed.
  
Actual results:
Segmentation fault

Expected results:
Return error to requests (reader not found).

Additional info:

(gdb) info threads
  Id   Target Id         Frame
* 8    Thread 0x7f99f3454700 (LWP 6405) "pcscd" 0x0000000000405c9b in IFDGetCapa
bilities (rContext=0x2787010, dwTag=4018, pdwLength=0x7f99f3433b98, pucValue=0x7
f99f3433ba0 "") at ifdwrapper.c:234
  2    Thread 0x7f99f3c55700 (LWP 5872) "pcscd"	_dl_close_worker (map=<value opt
imized out>) at dl-close.c:473
  1    Thread 0x7f99f3c56720 (LWP 5871) "pcscd"	0x0000003d9e4d6bc3 in select ()
at ../sysdeps/unix/syscall-template.S:82

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000405c9b in IFDGetCapabilities (rContext=0x2787010, dwTag=4018, pd
wLength=0x7f99f3433b98, pucValue=0x7f99f3433ba0 "") at ifdwrapper.c:234
#2  0x000000000040ef83 in SCardDisconnect (hCard=72929, dwDisposition=<value opt
imized out>) at winscard.c:984
#3  0x0000000000411737 in ContextThread (newContext=0x279e920) at winscard_svc.c
:475
#4  0x0000003d9f007cfb in start_thread (arg=0x7f99f3454700) at pthread_create.c:
301
#5  0x0000003d9e4dd6ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:
115

/usr/src/debug/pcsc-lite-1.6.6/src/ifdwrapper.c

233│ #ifndef PCSCLITE_STATIC_DRIVER
234├>        rv = (*IFDH_get_capabilities) (rContext->slot, dwTag, pdwLength, pu
235│ #else
236│         rv = IFDHGetCapabilities(rContext->slot, dwTag, pdwLength, pucValue
237│ #endif

(gdb) p	IFDH_get_capabilities
$3 = (RESPONSECODE (*)(DWORD, DWORD, PDWORD, PUCHAR)) 0

Seems like a simple fix (I know I should write a patch, but..)

Additional messages from /var/log/messages:

Feb  2 18:06:02 playa pcscd: winscard.c:290:SCardConnect() Card Not Inserted
Feb  2 18:06:02 playa pcscd: winscard_svc.c:443:ContextThread() CONNECT rv=0x8010000C for client 2
Feb  2 18:06:25 playa pcscd: winscard.c:290:SCardConnect() Card Not Inserted
Feb  2 18:06:25 playa pcscd: winscard_svc.c:443:ContextThread() CONNECT rv=0x8010000C for client 2
Feb  2 18:06:54 playa pcscd: winscard_svc.c:551:ContextThread() STATUS rv=0x80100069 for client 2
Feb  2 18:06:54 playa pcscd: winscard.c:290:SCardConnect() Card Not Inserted
Feb  2 18:06:54 playa pcscd: winscard_svc.c:443:ContextThread() CONNECT rv=0x8010000C for client 2
Feb  2 18:06:57 playa pcscd: ccid_usb.c:614:WriteUSB() write failed (1/22): -4 No such device
Feb  2 18:06:57 playa pcscd: ifdwrapper.c:354:IFDStatusICC() Card not transacted: 617
Feb  2 18:06:57 playa kernel: [33712.254620] usb 1-1.1: USB disconnect, address 22
Feb  2 18:06:58 playa pcscd: eventhandler.c:306:EHStatusHandlerThread() Error communicating to: Athena ASE IIIe [ASEDrive CCID] 00 00
Feb  2 18:06:58 playa pcscd: ccid_usb.c:614:WriteUSB() write failed (1/22): -4 No such device
Feb  2 18:06:58 playa pcscd: winscard_svc.c:551:ContextThread() STATUS rv=0x80100017 for client 2

Comment 1 Bob Relyea 2011-02-02 21:55:14 UTC
I'm not so sure it is a simple patch. The question here is why is IFDH_get_capabilities zero?

It comes from the function pointer in the context:

rContext->psFunctions.psFunctions_v2.pvfGetCapabilites

It would be good to know what rContext->psFunctions.psFunctions_v2 looked like (actually looking at *rContext would be good as well).

bob

Comment 2 Bob Relyea 2011-02-02 22:27:57 UTC
OK, the .psFunctions_v2.pvfGetCapabilities function is set in reader_factory.c. If the context was initialized, then there is no way that this function could be NULL, We could have failed to initialize the ifd_ handler and logged the "IFDHandler functions missing: GetCapabilities".

That means either 1) the rContext is not initialized properly, or 2) rContext is not really an rContext, or 3) rContext has been trashed by something.

I guess I would like to see the following:

1) start pcscd in the debugger with a break point at RFInitializeReader(). When RFInitializeReader returns print out *rContext. Do this for all calls to RFInitializeReader() (They should all be at the begining).

2) continue running pcsc until you fail. print out *rContext when you fail.

You can run pcscd in the debugger as follows:

As root:
# service pcscd stop
# gdb /usr/sbin/pcscd
gdb> {set break points}
gdb> run -d -f


-d tells pcscd to output lots of debugging info. -f tells pcscd not to daemonize (run in the foreground).

bob

Comment 3 Fedora End Of Life 2013-04-03 17:24:28 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 5 Fedora End Of Life 2015-01-09 16:32:26 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Fedora End Of Life 2015-02-17 13:36:10 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.