[Pcsclite-muscle] closing client cancels ongoing transaction
fhoerni at free.fr
Wed Sep 26 12:11:00 PDT 2018
Here is a sample code in C. It is not multi-thread nor multi-process,
but it reproduces the issue as well.
The output of this code (I added the line numbers):
1 init_client A
2 SCardEstablishContext: rv=0x0000
3 SCardListReaders: rv=0x0000
4 SCardConnect: rv=0x0000, hCard=3EDFCBA3
5 init_client B
6 SCardEstablishContext: rv=0x0000
7 SCardListReaders: rv=0x0000
8 SCardConnect: rv=0x0000, hCard=C8F61DB
9 SCardBeginTransaction B: rv=0x00000000
10 SCardReleaseContext A: rv=0x00000000
11 SCardTransmit B: rv=0x00000000
12 init_client C
13 SCardEstablishContext: rv=0x0000
14 SCardListReaders: rv=0x0000
15 SCardConnect: rv=0x0000, hCard=7EAF277F
16 SCardBeginTransaction C: rv=0x00000000
17 SCardTransmit C: rv=0x00000000
At line 16, the SCardBeginTransaction of client C should have returned an error.
At line 17, client C is disrupting client B.
After line 17, the SCardTransmit of client B is blocked, as client C has
not released the transaction.
On Wed, Sep 26, 2018 at 11:07:52AM +0200, Ludovic Rousseau wrote:
> Date: Wed, 26 Sep 2018 11:07:52 +0200
> From: Ludovic Rousseau <ludovic.rousseau at gmail.com>
> To: fhoerni at free.fr
> Cc: pcsclite-muscle at lists.infradead.org
> Subject: Re: [Pcsclite-muscle] closing client cancels ongoing transaction
> Le mar. 25 sept. 2018 à 21:55, Frederic Hoerni <fhoerni at free.fr> a écrit :
> > 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.
> Thanks a lot
> Dr. Ludovic Rousseau
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2264 bytes
Desc: not available
More information about the pcsclite-muscle