-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible use-after-free in RFReaderInfoById #140
Comments
I'm not entirely clear on the PC/SC-Lite's threading model, so not sure about the proper fix. Maybe we could keep the Or a new mutex has to be introduced, for operations with the whole |
The use case is: a reader is removed, and at the same time a PC/SC application is calling
A problem occurs if Is it the problem you are describing? A very long time ago pcsc-lite used only serial readers so with a static reader configuration and no hotplug. It is possible we missed something during the evolution :-) |
Exactly, that's the problematic scenario. I observed it under ASan, so it's a real UaF, even if pretty rare to happen in practice. I guess that there are also other similar race conditions between different threads accessing I can try preparing a patch that adds a new mutex for this structure, if you think this direction makes sense. (I suppose the only problem is that we should make sure we don't introduce any deadlock - and I myself am still not 100% sure in my understanding of the PC/SC-Lite's threading model.) |
Yes, I think we need a new Please propose a patch. |
@emaxx-google any news about a proposed patch? |
Sorry, I got distracted by some other high-priority things. Will try to get back to this soonish. |
Maybe issue #165 is a manifestation of this. |
@rohoog Maybe. Maybe not. I asked you to upgrade pcsc-lite and try again. This will allow me to know if your bug is already fixed or not. |
After a reader disappears,
RFReaderInfoById()
(for example, called fromSCardDisconnect()
) might try dereferencing anREADER_CONTEXT::handlesList
value that's already destroyed by the hotplug thread inremoveReader()
.UAF place:
PCSC/src/readerfactory.c
Line 860 in c35130f
Deallocation place:
PCSC/src/readerfactory.c
Line 699 in c35130f
P.S. It should supposedly be a very rare corner case, since normally readers aren't plugged and unplugged very often, and the overlap with another SCard operation on another thread should have right timing in order to trigger the issue.
The text was updated successfully, but these errors were encountered: