[Pcsclite-muscle] Rare race condition in SCardGetStatusChange()

[Ludovic Rousseau]

2018-04-17 15:12 GMT+02:00 Maximilian Stein <maximilian.stein at secunet.com>:
> Hello all,

Hello,

> recently we stumbled upon another (rare) race condition in the
> SCardGetStatusChange() function. I especially ask Maksim Ivanov and
> Florian Kaiser kindly to share their opinion about the problem and the
> proposed fix, since they did a good job in improving
> SCardGetStatusChange/SCardCancel in the recent past.

Nice explanation. Thanks.

> Suggestion for a fix:
> The proposed fix makes fetching the reader states and registering for
> event notifications an atomic action. The command
> CMD_WAIT_READER_STATE_CHANGE expected no return value anyway, so I made
> it return the reader states equal to CMD_GET_READERS_STATE. The action
> is protected by the ClientsWaitingForEvent_lock in eventhandler.c, which
> prevents parallel calls of MSGSignalClient() via
> EHSignalEventToClients(). This is necessary to prevent a signal before
> the reader states are sent, which would appear as garbage in the client
> socket.
>
> With the proposed fix, the client is registered for events after the
> reader states were fetched. So if any difference is found in the local
> and remote state (so that SCardGetStatusChange() returns) we have to
> unregister from events. This was not necessary before, but works just
> like unregistering after a timeout. This could be refined by checking
> why the loop was exited and only unregister if necessary.

In CMD_WAIT_READER_STATE_CHANGE case you add:
+#ifdef USE_USB
+                /* wait until all readers are ready */
+                RFWaitForReaderInit();
+#endif

Why?

Bye

-- 
 Dr. Ludovic Rousseau