[Pcsclite-muscle] closing client cancels ongoing transaction

Ludovic Rousseau ludovic.rousseau at gmail.com
Wed Sep 26 02:07:52 PDT 2018


Le mar. 25 sept. 2018 à 21:55, Frederic Hoerni <fhoerni at free.fr> a écrit :
> Hello,

Hello,

> 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.

Very interesting.
Can you provide a sample code in C or Python that exhibits the problem
so I can easily reproduce it?

Feel free to provide a patch or a git Pull Request. I will review it.
https://salsa.debian.org/rousseau/PCSC
https://github.com/LudovicRousseau/PCSC

Thanks a lot

-- 
 Dr. Ludovic Rousseau



More information about the pcsclite-muscle mailing list