fix: copy symmetric key on export to prevent JSI ArrayBuffer GC corruption#933
Merged
fix: copy symmetric key on export to prevent JSI ArrayBuffer GC corruption#933
Conversation
…ption (#645) exportKey() for SECRET keys returned the internal shared_ptr<ArrayBuffer> directly. When this crossed JSI to JS, Buffer.from(jsiArrayBuffer) created a zero-copy view. If GC reclaimed the JSI ArrayBuffer wrapper before the data was consumed, the view would see partially zeroed memory — explaining the intermittent trailing-zeros corruption reported in #645. Fix: Return a memcpy'd NativeArrayBuffer from C++ (matching the pattern used by all asymmetric key export paths), and force a copy in SecretKeyObject.export() via Buffer.from(new Uint8Array(key)) as defense-in-depth. Includes a 200-iteration stress test for generateKey → exportKey → importKey → encrypt → decrypt round-trips.
Remove redundant double-copy in TS (C++ already copies), trim verbose comment, and replace heuristic zero-byte test assertion with deterministic round-trip validation.
Contributor
🤖 End-to-End Test Results - iOSStatus: ✅ Passed 📸 Final Test ScreenshotScreenshot automatically captured from End-to-End tests and will expire in 30 days This comment is automatically updated on each test run. |
Contributor
🤖 End-to-End Test Results - AndroidStatus: ✅ Passed 📸 Final Test ScreenshotScreenshot automatically captured from End-to-End tests and will expire in 30 days This comment is automatically updated on each test run. |
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
1 participant
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.
Summary
Fixes an intermittent bug where
subtle.exportKey('raw')returns corrupted key data (trailing zeros) for symmetric keys. The root cause is a JSI ArrayBuffer lifetime issue:GetSymmetricKey()returned the internalshared_ptr<ArrayBuffer>directly, sharing memory with the JSI wrapper. When the JSI wrapper was garbage collected, the underlying memory could be freed while JavaScript still held aUint8Arrayview over it.Changes
HybridKeyObjectHandle.cpp): Return a copy viaToNativeArrayBuffer()instead of the internal key buffer directly, preventing GC corruption and protecting internal key material from mutationclasses.ts): Revert toBuffer.from(key)since the C++ layer now handles the copy (no need for double-copy viaUint8Array)import_export.ts): Add 200-iteration stress test that generates, exports, re-imports, and round-trips AES-CBC keys to validate the fix deterministicallyTesting
Run the
subtle/import_exporttest suite in the example app. The new#645 AES-CBC generateKey/exportKey/importKey stresstest exercises the fix with 200 iterations.Fixes #645