Repository navigation
Conversation
WP11_Object_Find walked the object list under the token lock, released the lock, and then read obj->handle and obj->opFlag. A concurrent C_DestroyObject of the same token object from another session could unlink and free the object in that window, which ASAN caught in concurrent_destroy_object_test. Read everything needed from the object, including the CKA_PRIVATE flag, while the token lock is held, and do not dereference it after the unlock. The slot lock used for the login state check is still only taken after the token lock is released, so the slot-then-token lock order is unchanged.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused fix protects lookup-time reads without changing lock ordering or introducing identified regressions.
0 open findings
What changed in this PR
Fixes a lookup-time use-after-free in WP11_Object_Find when another session concurrently destroys the object.
Changes:
- Keeps object traversal and private-flag reads under the token lock.
- Removes post-unlock object dereferences while preserving lock ordering.
| File | Description |
|---|---|
src/internal.c |
Extends lookup locking and captures the private flag before unlocking. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Member
Author
|
Superseded by #254, which now carries this fix as its own commit ("Fix use-after-free in WP11_Object_Find") together with the WP11_Lock fix and the TSAN changes it depends on. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WP11_Object_Findwalked the object list under the token lock, released it, and then readobj->handleandobj->opFlag(for theCKA_PRIVATEcheck). A concurrentC_DestroyObjectof the same token object from another session can unlink and free the object in that window. The sanitizer job hit this once on #247 (asan, PKCS#11 V3.2 PQC Build, run 38708225449): an 8-byte read inWP11_Object_Findcalled fromC_DestroyObjectinconcurrent_destroy_object_test, on memory just freed by the other destroyer thread. It is pre-existing; #247 does not touch this code.CKA_PRIVATEbit is captured while the lock is held.objis never dereferenced after the unlock.obj->handle == objHandlere-check is gone;ret == 0already means the walk matched.loginStateis still only taken after the token lock is released, so the slot-then-token lock order is unchanged.Testing:
DYLD_INSERT_LIBRARIESshim that sleeps briefly after some mutex unlocks on worker threads, the unfixed library failed 3 of 3 times within 9-17 s.make testpasses (debug and default configs).