[Pcsclite-muscle] closing client cancels ongoing transaction

Frederic Hoerni fhoerni at free.fr
Tue Sep 25 12:53:55 PDT 2018


I noticed the following behaviour on Linux (pcsc-lite v1.8.14 and v1.8.23).

(all clients below are threads or processes and talk to the same card
reader, in mode SCARD_SHARE_SHARED)

1. client A has a connection (SCardConnect)
2. client B connects, then starts a transaction (SCardBeginTransaction)
3. client A terminates
4. client C connects and starts a transaction (the transaction is accepted
   by the pcscd daemon)
5. client C talks to the smart card, and disrupts B

At step 4, the transaction should have been refused (or put on hold),
and at step 5, client B should not have been disrupted (step 5 is a
direct consequence of step 4).

My investigations show that the hLockId of the reader context is set to
client B at step 2, and then overwritten by zero at step 3. This happens
in MSGRemoveContext():

	rContext->hLockId = 0;

rContext->hLockId indicates which handler (as returned by SCardConnect) is
the owner of the transaction toward the card reader.

It looks like this line is a mistake for 2 reasons:
- firstly, it does not protect the modification of hLockId by a mutex
  (when it should);
- secondly, the releasing of hLockId (if necessary) is done in the code
  that follows, in SCardDisconnect().

If you confirm my analysis, I can submit a patch that, basically,
removes the line.


More information about the pcsclite-muscle mailing list