Skip to content

Avoid panicking when Windows memory is already unlocked - #22

Open
qtcqtc wants to merge 1 commit into
Eyob94:masterfrom
qtcqtc:fix/windows-drop-unlock
Open

Avoid panicking when Windows memory is already unlocked#22
qtcqtc wants to merge 1 commit into
Eyob94:masterfrom
qtcqtc:fix/windows-drop-unlock

Conversation

@qtcqtc

@qtcqtc qtcqtc commented Jul 30, 2026

Copy link
Copy Markdown

Summary

  • ignore VirtualUnlock failure during Drop on Windows
  • add a Windows regression test that drops multiple secrets sharing allocator pages

Why

VirtualLock does not maintain a lock count for overlapping pages. Heap allocations can share pages, so dropping one SecretBox may unlock a page shared with another. The later VirtualUnlock then reports ERROR_NOT_LOCKED. Panicking in Drop prevents reliable cleanup and can abort during unwinding.

The secret is still zeroized after the best-effort unlock.

Validation

  • cargo test on Windows: 6 passed
  • reproduced in a real rencfs Windows adapter lifecycle test before this change; that test passes with this patch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant