Timothy J. Miller wrote:
It looks to me that when session_FreeSession is called the session table has a stale pointer in it. I'm not familiar enough with the code to fix it (or figure out why it's happening in the first place) yet.
I'm not very good at this, so any help is appreciated. Stepping through a session close:
Stack:
session_FreeSession
slot_DisconnectSlot
slot_TokenChanged
closeSessionLocked
C_CloseSession
session_FreeSession returns, no problem. slot_DisconnectSlot removes a
slew of attributes and objects, and returns OK. slot_TokenChanged now
calls slot_UpdateSlot, which calls msc_WaitForTokenEvent:
Stack:
msc_WaitForTokenEvent
slot_UpdateSlot
slot_TokenChanged
closeSessionLocked
C_CloseSession
msc_WaitForTokenEvent returns error 0x9C59 (invalid handle), and we fall
back down to slot_TokenChanged. Next we call slot_BeginTransaction,
which calls slot_EstablishConnection, which calls msc_EstablishConnection.
Stack:
msc_EstablishConnection
slot_EstablishConnection
slot_BeginTransaction
slot_TokenChanged
closeSessionLocked
C_CloseSession
msc_EstablishConnection returns the same error as msc_WaitForTokenEvent
(0x9C59 invalid handle) and fall back down to slot_TokenChanged (logging
CKR_FUNCTION_FAILED twice along the way) and thence back to
closeSessionLocked.
Next we call session_FreeSession again:
Stack:
session_FreeSession
closeSessionLocked
C_CloseSession
And it's during this invocation that we dereference prev->hnext, where
prev appears to be a stale pointer entry in the session hash table.
Now I don't even begin to grasp all that's going on here, but it seems to me that it's the second entry to session_FreeSession from closeSessionLocked that's the problem.
This whole process looks to me like it's detecting a token change (removal), deleting the session, returning the wrong error code because of the function failed errors, and then launching us into the second slot_FreeSession call which is dereferencing a stale pointer.
What's odd about all this is -- I never removed the token. I don't understand why slot_TokenChanged is doing what it's doing.
Is this a bug? How can I fix it? -- Tim
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
