Bug with SCardCancel followed by new requests on the waiting thread

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug with SCardCancel followed by new requests on the waiting thread

Maksim Ivanov
Hello all,

Looks like there is a bug related to the management of the blocking
requests and of their cancellation.

The reproduce steps are the following. Two threads: thread 1 and
thread 2. Thread 2 calls SCardGetStatusChange and blocks (with waiting
for some event X). Thread 1 calls SCardCancel. Thread 2 unblocks from
SCardGetStatusChange due to the cancellation, and starts issuing other
PC/SC-Lite API calls. After that, something that triggers the event X
happens. After that the PC/SC-Lite API calls that thread 2 is making
start to break (they return inconsistent results).

The underlying reason is that cancellation in the current
implementation of the PC/SC-Lite service does not unsubscribe the
client from the list of clients waiting for events. So, when the event
finally occurs, the event response is written into the client's
socket, even if the cancellation had already happened before. Putting
unexpected data into the socket shifts the responses of all further
PC/SC-Lite API calls made by that client.

If the analysis above is correct, then the correct fix would be
probably just adding a "EHTryToUnregisterClientForEvent(fd)" statement
into the handler of the SCARD_CANCEL message in function ContextThread
(file winscard_svc.c).


Thanks,
Maksim

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Bug with SCardCancel followed by new requests on the waiting thread

Ludovic Rousseau
2016-03-10 20:01 GMT+01:00 Maksim Ivanov <[hidden email]>:
Hello all,

Hello Maksim,
 

Looks like there is a bug related to the management of the blocking
requests and of their cancellation.

The reproduce steps are the following. Two threads: thread 1 and
thread 2. Thread 2 calls SCardGetStatusChange and blocks (with waiting
for some event X). Thread 1 calls SCardCancel. Thread 2 unblocks from
SCardGetStatusChange due to the cancellation, and starts issuing other
PC/SC-Lite API calls. After that, something that triggers the event X
happens. After that the PC/SC-Lite API calls that thread 2 is making
start to break (they return inconsistent results).

The underlying reason is that cancellation in the current
implementation of the PC/SC-Lite service does not unsubscribe the
client from the list of clients waiting for events. So, when the event
finally occurs, the event response is written into the client's
socket, even if the cancellation had already happened before. Putting
unexpected data into the socket shifts the responses of all further
PC/SC-Lite API calls made by that client.

If the analysis above is correct, then the correct fix would be
probably just adding a "EHTryToUnregisterClientForEvent(fd)" statement
into the handler of the SCARD_CANCEL message in function ContextThread
(file winscard_svc.c).

You are right.

Fixed in 57b0ba5a200bcbf1c489d39261340324392a8e8a

Thanks for the analysis and proposed patch.

Please tell me when you have finished your code review so I can publish a new version of pcsc-lite with all the fixes :-)

Bye

--
 Dr. Ludovic Rousseau

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Bug with SCardCancel followed by new requests on the waiting thread

Maksim Ivanov
Hello Ludovic,

Thanks for the quick reply.


> Please tell me when you have finished your code review so I can publish a
> new version of pcsc-lite with all the fixes :-)

Actually, this was the only bug that I met.


Thanks,
Maksim


On Fri, Mar 11, 2016 at 11:52 AM, Ludovic Rousseau
<[hidden email]> wrote:

> 2016-03-10 20:01 GMT+01:00 Maksim Ivanov <[hidden email]>:
>>
>> Hello all,
>
>
> Hello Maksim,
>
>>
>>
>> Looks like there is a bug related to the management of the blocking
>> requests and of their cancellation.
>>
>> The reproduce steps are the following. Two threads: thread 1 and
>> thread 2. Thread 2 calls SCardGetStatusChange and blocks (with waiting
>> for some event X). Thread 1 calls SCardCancel. Thread 2 unblocks from
>> SCardGetStatusChange due to the cancellation, and starts issuing other
>> PC/SC-Lite API calls. After that, something that triggers the event X
>> happens. After that the PC/SC-Lite API calls that thread 2 is making
>> start to break (they return inconsistent results).
>>
>> The underlying reason is that cancellation in the current
>> implementation of the PC/SC-Lite service does not unsubscribe the
>> client from the list of clients waiting for events. So, when the event
>> finally occurs, the event response is written into the client's
>> socket, even if the cancellation had already happened before. Putting
>> unexpected data into the socket shifts the responses of all further
>> PC/SC-Lite API calls made by that client.
>>
>> If the analysis above is correct, then the correct fix would be
>> probably just adding a "EHTryToUnregisterClientForEvent(fd)" statement
>> into the handler of the SCARD_CANCEL message in function ContextThread
>> (file winscard_svc.c).
>
>
> You are right.
>
> Fixed in 57b0ba5a200bcbf1c489d39261340324392a8e8a
>
> Thanks for the analysis and proposed patch.
>
> Please tell me when you have finished your code review so I can publish a
> new version of pcsc-lite with all the fixes :-)
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> Pcsclite-muscle mailing list
> [hidden email]
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle