Bug 956530 - pcsc-lite deadlocks due to unreleased mutex
Summary: pcsc-lite deadlocks due to unreleased mutex
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pcsc-lite
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Bob Relyea
QA Contact: Asha Akkiangady
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-25 07:31 UTC by Fredrik Axelsson
Modified: 2015-07-22 07:06 UTC (History)
5 users (show)

Fixed In Version: pcsc-lite-1.5.2-15.el6
Doc Type: Bug Fix
Doc Text:
Previously, after a card reader went offline when the user entered the settings menu, the pcsc-lite client could under certain circumstances enter a deadlock state and never recover from it. The underlying source code has been modified so that the client does not wait for an unreleased mutex. As a result, the client does not enter a deadlock state in the described situation, and the reader is accessible again after it returns online. (BZ#956530)
Clone Of:
Environment:
Last Closed: 2015-07-22 07:06:00 UTC


Attachments (Terms of Use)
Suggested patch (836 bytes, application/octet-stream)
2013-04-25 07:31 UTC, Fredrik Axelsson
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1369 normal SHIPPED_LIVE pcsc-lite bug fix update 2015-07-20 17:58:52 UTC

Description Fredrik Axelsson 2013-04-25 07:31:56 UTC
Created attachment 739694 [details]
Suggested patch

Description of problem:
A pcsc-lite client program can be deadlocked due to an unreleased mutex in SCardBeginTransaction. This can happen when a smart card reader, temporarily, stops responding.

Version-Release number of selected component (if applicable):
pcsc-lite-1.5.2-11.el6

How reproducible:
Always reproducible with the card reader we have which goes "off-line" when entering a settings menu.

Steps to Reproduce:
1. A client program performs continuous calls to SCard-functions, e.g. SCardGetStatusChange(SCARD_STATE_UNAWARE). 
2. Take reader off-line by entering an on-reader settings menu.
3. Take the reader on-line again by leaving the settings menu.
  
Actual results:
The client program will deadlock and never recover. It waits for a mutex that was never released in an earlier call to SCardBeginTransaction.

Expected results:
The client program should not deadlock and the reader should be accessible again after returning on-line.

Additional info:
Here's a patch that fixes the problem:

diff --git a/src/winscard_clnt.c b/src/winscard_clnt.c
index c190f45..1819158 100644
--- a/src/winscard_clnt.c
+++ b/src/winscard_clnt.c
@@ -1149,10 +1149,19 @@ LONG SCardBeginTransaction(SCARDHANDLE hCard)
 	/* check the handle is still valid */
 	rv = SCardGetIndicesFromHandle(hCard, &dwContextIndex, &dwChannelIndex);
 	if (rv == -1)
+	{
 		/* the handle is now invalid
 		 * -> another thread may have called SCardReleaseContext
 		 * -> so the mMutex has been unlocked */
+
+		/* fredrik.axelsson@link22.se: The comment above about
+		 * the mutex can't be correct. The mutex is held by
+		 * this thread and must be release by this thread before
+		 * returning. */
+		(void)SYS_MutexUnLock(psContextMap[dwContextIndex].mMutex);
+
 		return SCARD_E_INVALID_HANDLE;
+	}
 
 	for (i = 0; i < PCSCLITE_MAX_READERS_CONTEXTS; i++)
 	{

Comment 1 Ludovic Rousseau 2013-04-25 11:09:58 UTC
Can you reproduce the bug with pcsc-lite 1.5.5?

An even better solution is to upgrade and check with pcsc-lite 1.8.8 (latest version)

Comment 2 Fredrik Axelsson 2013-04-25 14:33:54 UTC
Tested with pcsc-lite 1.8.8. Problem is the same and the same suggested patch fixes it. IMHO it's plain that the mutex isn't released if SCardGetIndicesFromHandle fails. Releasing the mutex before returning from SCardBeginTransaction must be the right thing to do.

Comment 4 Ludovic Rousseau 2013-04-25 18:53:46 UTC
Since you now have pcsc-lite 1.8.8 can you use libpcscspy.so.0 to generate a log file (cat ~/pcsc-spy > logfile) and attach it here?

See http://ludovicrousseau.blogspot.fr/2011/11/pcsc-api-spy-third-try.html

Comment 5 Fredrik Axelsson 2013-04-26 13:47:40 UTC
I can't trigger the problem with pcsc-spy activated and only seldom with the regular libpcsclite.so version 1.8.8. Version 1.8.8 seems to have different timing than 1.5.2 where I can trigger the deadlock 100% of the times I try.

I realize that my case is a bit weak and might not be an issue for anyone that doesn't need to use the smart card reader we use (Swedish Defense KT2).

I do however believe that many of the functions in winscard_clnt.c can potentialy cause deadlocks because they have return paths that don't unlock context mutexes.

Comment 6 Ludovic Rousseau 2013-04-26 16:49:59 UTC
Can you point me to a winscard_clnt.c function that can cause a deadlock for version 1.8.8?

Comment 7 Fredrik Axelsson 2013-04-29 06:18:20 UTC
The few time the deadlock occurred in 1.8.8  it was cased by returning from SCardBeginTransaction while still holding the mutex. I know this because I put printfs just before the return statement in every SCard-function that has the same logic, i.e. check the return value from SCardGetContextFromChannel and if -1, return without unlocking the mutex. Every time my test application got stuck waiting for a mutex in a call to SCardGetStatusChange, I could see from a printout from SCardBeginTransaction that it had returned prematurely.

Comment 8 Ludovic Rousseau 2013-05-27 14:41:29 UTC
Fredrik, I reviewed the code and I am puzzled by your bug.

In 1.8.8 the only way to return from SCardBeginTransaction is either:
- at the end after unlocking the lock
- in case SCardGetContextAndChannelFromHandle() fails

If SCardGetContextAndChannelFromHandle() fails it indicated the hCard parameter has been invalidated (the parameter hCard was valid on the initial SCardGetContextAndChannelFromHandle() call).

hCard is now invalid because SCardDisconnect() has been called for this hCard.
And if SCardDisconnect() has been called then the mutex has been released.

It would really help if you could reproduce the problem using pcsc-lite 1.8.8 and pcsc-spy to get a trace of the calls.

Comment 9 Ludovic Rousseau 2013-05-30 11:22:48 UTC
The bug has been fixed in revision 6639.
http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2013-May/006192.html

I will release a new version of pcsc-lite with the bug fixed "soon".

Thanks

Comment 10 RHEL Product and Program Management 2013-10-14 03:43:10 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 11 Asha Akkiangady 2014-04-23 15:22:14 UTC
Please provide steps to test and verify this. Also, what type of smart card and the reader is used?

Comment 12 Fredrik Axelsson 2014-04-24 07:13:05 UTC
(In reply to Asha Akkiangady from comment #11)
> Please provide steps to test and verify this. Also, what type of smart card
> and the reader is used?

I have verified this in the test setup I have. Problem is that the card and reader are specific to the Swedish Defense and not publically available.

Also note that the software that triggered this bug was not well-behaved and had itself threading issues. This was pointed out to me by Ludovic Rousseau and fixing that issue caused the bug not to be triggered.

To summarize: I believe that the bug is fixed and I have verified this but I can't think of a way for anyone else to test it.

Comment 14 Asha Akkiangady 2014-12-08 21:17:07 UTC
It appears that this is an environment issue, not a pcsc-lite bug. Can we close this bug as NOTABUG?

Comment 15 Asha Akkiangady 2014-12-08 22:23:42 UTC
Looks like upstream patch that still needs to be applied to RHEL 6.

Comment 16 Bob Relyea 2015-02-27 01:44:00 UTC
Upstream patch applied (modified appropriately for the older code base).

Comment 18 Roshni 2015-04-14 16:29:47 UTC
[root@dhcp129-124 ~]# rpm -qi pcsc-lite
Name        : pcsc-lite                    Relocations: (not relocatable)
Version     : 1.5.2                             Vendor: Red Hat, Inc.
Release     : 15.el6                        Build Date: Thu 26 Feb 2015 08:39:13 PM EST
Install Date: Fri 10 Apr 2015 12:06:37 PM EDT      Build Host: x86-031.build.eng.bos.redhat.com
Group       : System Environment/Daemons    Source RPM: pcsc-lite-1.5.2-15.el6.src.rpm
Size        : 402732                           License: BSD
Signature   : RSA/8, Wed 04 Mar 2015 07:22:07 AM EST, Key ID 938a80caf21541eb
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://pcsclite.alioth.debian.org/
Summary     : PC/SC Lite smart card framework and applications

Sanity only, all supported smartcards were detected.

Comment 20 errata-xmlrpc 2015-07-22 07:06:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1369.html


Note You need to log in before you can comment on or make changes to this bug.