[Pcsclite-muscle] closing client cancels ongoing transaction
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
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