[Pcsclite-muscle] closing client cancels ongoing transaction

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

--
Frederic

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,
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_client2.c
Type: text/x-csrc
Size: 2264 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20180926/0e035272/attachment.bin>


More information about the pcsclite-muscle mailing list