During OpenSSL callbacks, calling OpenSSL functions is unsafe

[divVerent]

Version

v26.5.0

Platform

Darwin rpolzer-macbookpro.roam.internal 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun 9 22:18:58 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6000 arm64

Subsystem

ssl_tls

What steps will reproduce the bug?

• Calling this._handle.destroySSL() from within the ALPNCallback
• Calling client._handle.setServername('...') from within the on('keylog') callback
• Calling this.write('...') from within the ALPNCallback

How often does it reproduce? Is there a required condition?

All of these reproduce every time.

What is the expected behavior? Why is that the expected behavior?

No segfault, no abort, no deadlock - just JS exceptions.

What do you see instead?

• Calling this._handle.destroySSL() from within the ALPNCallback causes segfault of NodeJS:

* thread #1, name = 'node-MainThread', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
 * frame #0: 0x0000000188addaf4 libsystem_malloc.dylib`malloc_error_break
 frame #1: 0x0000000188ab19ac libsystem_malloc.dylib`malloc_vreport + 744
 frame #2: 0x0000000188ab528c libsystem_malloc.dylib`malloc_report + 64
 frame #3: 0x0000000188aba648 libsystem_malloc.dylib`___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED + 76
 frame #4: 0x0000000100806e20 libssl.3.dylib`tls_post_process_client_hello + 432
 frame #5: 0x00000001007f6398 libssl.3.dylib`state_machine + 1424
 frame #6: 0x00000001007e369c libssl.3.dylib`ssl3_read_bytes + 1788
 frame #7: 0x00000001007982d4 libssl.3.dylib`ssl3_read_internal + 136
 frame #8: 0x00000001007a34fc libssl.3.dylib`SSL_read + 28
 frame #9: 0x0000000104b017cc libnode.147.dylib`node::crypto::TLSWrap::ClearOut() + 324
 frame #10: 0x0000000104b00c4c libnode.147.dylib`node::crypto::TLSWrap::Cycle() + 52
 frame #11: 0x0000000104b03558 libnode.147.dylib`node::crypto::TLSWrap::OnStreamRead(long, uv_buf_t const&) + 124
 frame #12: 0x0000000104a7d40c libnode.147.dylib`node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) + 780
 frame #13: 0x0000000104a7d810 libnode.147.dylib`node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s*, long, uv_buf_t const*) + 88
 frame #14: 0x0000000100080660 libuv.1.dylib`uv__stream_io + 1000
 frame #15: 0x00000001000851b0 libuv.1.dylib`uv__io_poll + 1252
 frame #16: 0x0000000100076b64 libuv.1.dylib`uv_run + 276
 frame #17: 0x0000000104904fd0 libnode.147.dylib`node::SpinEventLoopInternal(node::Environment*) + 252
 frame #18: 0x00000001049dbdd0 libnode.147.dylib`node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) + 184
 frame #19: 0x00000001049dbb04 libnode.147.dylib`node::NodeMainInstance::Run() + 140
 frame #20: 0x000000010497cfac libnode.147.dylib`node::Start(int, char**) + 684
 frame #21: 0x00000001888f3e00 dyld`start + 6992

• Calling client._handle.setServername('...') from within the on('keylog') callback causes assertion failure of NodeJS:

 # node[11780]: static void node::crypto::TLSWrap::SetServername(const FunctionCallbackInfo<Value> &) at ../src/crypto/crypto_tls.cc:1381
 # Assertion failed: !wrap->started_

----- Native stack trace -----

 1: 0x105e96010 node::Assert(node::AssertionInfo const&) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
 2: 0x105f27aec node::crypto::TLSWrap::SetServername(v8::FunctionCallbackInfo<v8::Value> const&) (.cold.5) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
 3: 0x104ec407c node::crypto::TLSWrap::SetServername(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
 4: 0x10579720c Builtins_CallApiCallbackGeneric [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
 5: 0x105795424 Builtins_InterpreterEntryTrampoline [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
 6: 0x1175013b0 
 7: 0x105795424 Builtins_InterpreterEntryTrampoline [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
 8: 0x105792788 Builtins_JSEntryTrampoline [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
 9: 0x105792478 Builtins_JSEntry [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
10: 0x105010884 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
11: 0x1050102bc v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>, v8::base::Vector<v8::internal::DirectHandle<v8::internal::Object> const>) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
12: 0x105f2e540 v8::Function::Call(v8::Isolate*, v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
13: 0x104cc4310 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context, v8::Local<v8::Value>) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
14: 0x104cd2e6c node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
15: 0x105f24cd0 node::crypto::(anonymous namespace)::KeylogCallback(ssl_st const*, char const*) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
16: 0x100941234 nss_keylog_int [/Users/rpolzer/homebrew/Cellar/openssl@3/3.6.3/lib/libssl.3.dylib]
17: 0x1009533ac tls13_change_cipher_state [/Users/rpolzer/homebrew/Cellar/openssl@3/3.6.3/lib/libssl.3.dylib]
18: 0x1009916cc tls_process_server_hello [/Users/rpolzer/homebrew/Cellar/openssl@3/3.6.3/lib/libssl.3.dylib]
19: 0x10098e468 state_machine [/Users/rpolzer/homebrew/Cellar/openssl@3/3.6.3/lib/libssl.3.dylib]
20: 0x10097b69c ssl3_read_bytes [/Users/rpolzer/homebrew/Cellar/openssl@3/3.6.3/lib/libssl.3.dylib]
21: 0x1009302d4 ssl3_read_internal [/Users/rpolzer/homebrew/Cellar/openssl@3/3.6.3/lib/libssl.3.dylib]
22: 0x10093b4fc SSL_read [/Users/rpolzer/homebrew/Cellar/openssl@3/3.6.3/lib/libssl.3.dylib]
23: 0x104ec17cc node::crypto::TLSWrap::ClearOut() [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
24: 0x104ec0c4c node::crypto::TLSWrap::Cycle() [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
25: 0x104ec3558 node::crypto::TLSWrap::OnStreamRead(long, uv_buf_t const&) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
26: 0x104e3d40c node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
27: 0x104e3d810 node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s*, long, uv_buf_t const*) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
28: 0x100258660 uv__stream_io [/Users/rpolzer/homebrew/Cellar/libuv/1.52.1/lib/libuv.1.0.0.dylib]
29: 0x10025d1b0 uv__io_poll [/Users/rpolzer/homebrew/Cellar/libuv/1.52.1/lib/libuv.1.0.0.dylib]
30: 0x10024eb64 uv_run [/Users/rpolzer/homebrew/Cellar/libuv/1.52.1/lib/libuv.1.0.0.dylib]
31: 0x104cc4fd0 node::SpinEventLoopInternal(node::Environment*) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
32: 0x104d9bdd0 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
33: 0x104d9bb04 node::NodeMainInstance::Run() [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
34: 0x104d3cfac node::Start(int, char**) [/Users/rpolzer/homebrew/Cellar/node/26.5.0/lib/libnode.147.dylib]
35: 0x1888f3e00 start [/usr/lib/dyld]

----- JavaScript stack trace -----

1: /private/tmp/z.js:41:23
2: emit (node:events:509:20)
3: onkeylog (node:internal/tls/wrap:554:22)

• Calling this.write('...') from within the ALPNCallback causes deadlock (due to SSL_write within SSL_do_handshake), the SSL state machine seems to never finish, so the tls.connect callback never runs.

Additional information

I can provide the exact .js files upon request.

It would help if this._handle were not accessible but hidden within a closure, but it would not be sufficient (as you see, the deadlock one doesn't even need this).

We plan to harden BoringSSL against issues like this by having reentrant or concurrent calls to SSL * functions (and maybe others) return a new ERR_R_BAD_CONCURRENCY which would safely prevent such issues; it would however force NodeJS to move to a different approach of providing these callbacks. In particular, NodeJS's own test suite assumes that you can call write from onhandshakedone, which, albeit convenient, breaks invariants within both OpenSSL and BoringSSL and just "happens to work" for now, but will be broken by the pending change.

You can look at our pending patch for BoringSSL here: https://boringssl-review.googlesource.com/c/boringssl/+/97087 - this issue was actually found by testing this patch against known code bases.

Possible solutions include:

• Set a flag while in an OpenSSL callback, and have further SSL methods check that flag and throw immediately.
• Defer callbacks to the next frame where possible (primarily, where the callback's return value is not needed).

See also a related issue in CPython, found by the same audit: python/cpython#143756

[wafir645fcqs4]

Thanks for reporting this and for the detailed investigation. Deferring or guarding these callbacks seems like a sensible approach to avoid unsafe reentrant OpenSSL calls. Looking forward to the discussion on the best implementation.

…

On Wed, Aug 5, 2026 at 8:11 AM divVerent ***@***.***> wrote: *divVerent* created an issue (nodejs/node#65035) <#65035> Version v26.5.0 Platform Darwin rpolzer-macbookpro.roam.internal 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun 9 22:18:58 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6000 arm64 Subsystem ssl_tls What steps will reproduce the bug? - Calling this._handle.destroySSL() from within the ALPNCallback - Calling client._handle.setServername('...') from within the on('keylog') callback - Calling this.write('...') from within the ALPNCallback How often does it reproduce? Is there a required condition? All of these reproduce every time. What is the expected behavior? Why is that the expected behavior? No segfault, no abort, no deadlock - just JS exceptions. What do you see instead? - Calling this._handle.destroySSL() from within the ALPNCallback causes segfault of NodeJS: * thread #1, name = 'node-MainThread', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000188addaf4 libsystem_malloc.dylib`malloc_error_break frame #1: 0x0000000188ab19ac libsystem_malloc.dylib`malloc_vreport + 744 frame #2: 0x0000000188ab528c libsystem_malloc.dylib`malloc_report + 64 frame #3: 0x0000000188aba648 libsystem_malloc.dylib`___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED + 76 frame #4: 0x0000000100806e20 libssl.3.dylib`tls_post_process_client_hello + 432 frame #5: 0x00000001007f6398 libssl.3.dylib`state_machine + 1424 frame #6: 0x00000001007e369c libssl.3.dylib`ssl3_read_bytes + 1788 frame #7: 0x00000001007982d4 libssl.3.dylib`ssl3_read_internal + 136 frame #8: 0x00000001007a34fc libssl.3.dylib`SSL_read + 28 frame #9: 0x0000000104b017cc libnode.147.dylib`node::crypto::TLSWrap::ClearOut() + 324 frame #10: 0x0000000104b00c4c libnode.147.dylib`node::crypto::TLSWrap::Cycle() + 52 frame #11: 0x0000000104b03558 libnode.147.dylib`node::crypto::TLSWrap::OnStreamRead(long, uv_buf_t const&) + 124 frame #12: 0x0000000104a7d40c libnode.147.dylib`node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) + 780 frame #13: 0x0000000104a7d810 libnode.147.dylib`node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s*, long, uv_buf_t const*) + 88 frame #14: 0x0000000100080660 libuv.1.dylib`uv__stream_io + 1000 frame #15: 0x00000001000851b0 libuv.1.dylib`uv__io_poll + 1252 frame #16: 0x0000000100076b64 libuv.1.dylib`uv_run + 276 frame #17: 0x0000000104904fd0 libnode.147.dylib`node::SpinEventLoopInternal(node::Environment*) + 252 frame #18: 0x00000001049dbdd0 libnode.147.dylib`node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) + 184 frame #19: 0x00000001049dbb04 libnode.147.dylib`node::NodeMainInstance::Run() + 140 frame #20: 0x000000010497cfac libnode.147.dylib`node::Start(int, char**) + 684 frame #21: 0x00000001888f3e00 dyld`start + 6992 - Calling client._handle.setServername('...') from within the on('keylog') callback causes assertion failure of NodeJS: # node[9656]: static void node::crypto::TLSWrap::SetServername(const FunctionCallbackInfo<Value> &) at ../src/crypto/crypto_tls.cc:1381 # Assertion failed: !wrap->started_ - Calling this.write('...') from within the ALPNCallback causes deadlock (due to SSL_write within SSL_do_handshake). Additional information I can provide the exact .js files upon request. It would help if this._handle were not accessible but hidden within a closure, but it would not be sufficient (as you see, the deadlock one doesn't even need this). We plan to harden BoringSSL against issues like this by having reentrant or concurrent calls to SSL * functions (and maybe others) return a new ERR_R_BAD_CONCURRENCY which would safely prevent such issues; it would however force NodeJS to move to a different approach of providing these callbacks. In particular, NodeJS's own test suite assumes that you can call write from onhandshakedone, which, albeit convenient, breaks invariants within both OpenSSL and BoringSSL and just "happens to work" for now, but will be broken by the pending change. You can look at our pending patch for BoringSSL here: https://boringssl-review.googlesource.com/c/boringssl/+/97087 - this issue was actually found by testing this patch against known code bases. Possible solutions include: - Set a flag while in an OpenSSL callback, and have further SSL methods check that flag and throw immediately. - Defer callbacks to the next frame where possible (primarily, where the callback's return value is not needed). See also a related issue in CPython, found by the same audit: python/cpython#143756 <python/cpython#143756> — Reply to this email directly, view it on GitHub <#65035?email_source=notifications&email_token=CKTGBQILOTXE3TAY2LG3PIT5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CKTGBQJ4NBH7OIJOL5H3AI35ILFZFAVCNFSNUABEKJSXA33TNF2G64TZHMZDOMJZGM3TOOJ3JFZXG5LFHM2TANRXHEYTCMBVGCQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CKTGBQIBZI54TQ27AA74TIT5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CKTGBQPX62RIEW64IO4O2WL5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wafir645fcqs46]

Thanks for the detailed report and analysis. Guarding against reentrant OpenSSL calls or deferring callbacks both seem like reasonable approaches. Looking forward to seeing which solution the maintainers settle on. On Wed, Aug 5, 2026 at 10:16 AM wafir645fcqs4 ***@***.***> wrote:

…

*wafir645fcqs4* left a comment (nodejs/node#65035) <#65035 (comment)> Thanks for reporting this and for the detailed investigation. Deferring or guarding these callbacks seems like a sensible approach to avoid unsafe reentrant OpenSSL calls. Looking forward to the discussion on the best implementation. On Wed, Aug 5, 2026 at 8:11 AM divVerent ***@***.***> wrote: > *divVerent* created an issue (nodejs/node#65035) > <#65035> > Version > > v26.5.0 > Platform > > Darwin rpolzer-macbookpro.roam.internal 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun 9 22:18:58 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6000 arm64 > > Subsystem > > ssl_tls > What steps will reproduce the bug? > > - Calling this._handle.destroySSL() from within the ALPNCallback > - Calling client._handle.setServername('...') from within the > on('keylog') callback > - Calling this.write('...') from within the ALPNCallback > > How often does it reproduce? Is there a required condition? > > All of these reproduce every time. > What is the expected behavior? Why is that the expected behavior? > > No segfault, no abort, no deadlock - just JS exceptions. > What do you see instead? > > - Calling this._handle.destroySSL() from within the ALPNCallback > causes segfault of NodeJS: > > * thread #1, name = 'node-MainThread', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 > * frame #0: 0x0000000188addaf4 libsystem_malloc.dylib`malloc_error_break > frame #1: 0x0000000188ab19ac libsystem_malloc.dylib`malloc_vreport + 744 > frame #2: 0x0000000188ab528c libsystem_malloc.dylib`malloc_report + 64 > frame #3: 0x0000000188aba648 libsystem_malloc.dylib`___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED + 76 > frame #4: 0x0000000100806e20 libssl.3.dylib`tls_post_process_client_hello + 432 > frame #5: 0x00000001007f6398 libssl.3.dylib`state_machine + 1424 > frame #6: 0x00000001007e369c libssl.3.dylib`ssl3_read_bytes + 1788 > frame #7: 0x00000001007982d4 libssl.3.dylib`ssl3_read_internal + 136 > frame #8: 0x00000001007a34fc libssl.3.dylib`SSL_read + 28 > frame #9: 0x0000000104b017cc libnode.147.dylib`node::crypto::TLSWrap::ClearOut() + 324 > frame #10: 0x0000000104b00c4c libnode.147.dylib`node::crypto::TLSWrap::Cycle() + 52 > frame #11: 0x0000000104b03558 libnode.147.dylib`node::crypto::TLSWrap::OnStreamRead(long, uv_buf_t const&) + 124 > frame #12: 0x0000000104a7d40c libnode.147.dylib`node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) + 780 > frame #13: 0x0000000104a7d810 libnode.147.dylib`node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s*, long, uv_buf_t const*) + 88 > frame #14: 0x0000000100080660 libuv.1.dylib`uv__stream_io + 1000 > frame #15: 0x00000001000851b0 libuv.1.dylib`uv__io_poll + 1252 > frame #16: 0x0000000100076b64 libuv.1.dylib`uv_run + 276 > frame #17: 0x0000000104904fd0 libnode.147.dylib`node::SpinEventLoopInternal(node::Environment*) + 252 > frame #18: 0x00000001049dbdd0 libnode.147.dylib`node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) + 184 > frame #19: 0x00000001049dbb04 libnode.147.dylib`node::NodeMainInstance::Run() + 140 > frame #20: 0x000000010497cfac libnode.147.dylib`node::Start(int, char**) + 684 > frame #21: 0x00000001888f3e00 dyld`start + 6992 > > > - Calling client._handle.setServername('...') from within the > on('keylog') callback causes assertion failure of NodeJS: > > # node[9656]: static void node::crypto::TLSWrap::SetServername(const FunctionCallbackInfo<Value> &) at ../src/crypto/crypto_tls.cc:1381 > # Assertion failed: !wrap->started_ > > > - Calling this.write('...') from within the ALPNCallback causes > deadlock (due to SSL_write within SSL_do_handshake). > > Additional information > > I can provide the exact .js files upon request. > > It would help if this._handle were not accessible but hidden within a > closure, but it would not be sufficient (as you see, the deadlock one > doesn't even need this). > > We plan to harden BoringSSL against issues like this by having reentrant > or concurrent calls to SSL * functions (and maybe others) return a new > ERR_R_BAD_CONCURRENCY which would safely prevent such issues; it would > however force NodeJS to move to a different approach of providing these > callbacks. In particular, NodeJS's own test suite assumes that you can call > write from onhandshakedone, which, albeit convenient, breaks invariants > within both OpenSSL and BoringSSL and just "happens to work" for now, but > will be broken by the pending change. > > You can look at our pending patch for BoringSSL here: > https://boringssl-review.googlesource.com/c/boringssl/+/97087 - this > issue was actually found by testing this patch against known code bases. > > Possible solutions include: > > - Set a flag while in an OpenSSL callback, and have further SSL > methods check that flag and throw immediately. > - Defer callbacks to the next frame where possible (primarily, where > the callback's return value is not needed). > > See also a related issue in CPython, found by the same audit: > python/cpython#143756 <python/cpython#143756> > > — > Reply to this email directly, view it on GitHub > < #65035?email_source=notifications&email_token=CKTGBQILOTXE3TAY2LG3PIT5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/CKTGBQJ4NBH7OIJOL5H3AI35ILFZFAVCNFSNUABEKJSXA33TNF2G64TZHMZDOMJZGM3TOOJ3JFZXG5LFHM2TANRXHEYTCMBVGCQXMAQ> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > < https://github.com/notifications/mobile/ios/CKTGBQIBZI54TQ27AA74TIT5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> > and Android > < https://github.com/notifications/mobile/android/CKTGBQPX62RIEW64IO4O2WL5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. > Download it today! > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#65035?email_source=notifications&email_token=CKTGG2SXP56ZJQPKVJRBCUD5ILUPNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTENJSHE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5189325295>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CKTGG2XDZ2IPGD4GXQBMTJ35ILUPNAVCNFSNUABEKJSXA33TNF2G64TZHMZDOMJZGM3TOOJ3JFZXG5LFHM2TANRXHEYTCMBVGCQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CKTGG2UJA4GYB4UFJBX5FJL5ILUPNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTENJSHE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CKTGG2VJT3T36GRAVW72FUD5ILUPNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTENJSHE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wafir645fcqs8]

Thanks for pointing that out. Adding a brief note explaining why indA & indB behaves differently from indA.intersection(indB) would definitely make the example clearer and help avoid confusion for readers. On Wed, Aug 5, 2026 at 10:23 AM wafir645fcqs46 ***@***.***> wrote:

…

*wafir645fcqs46* left a comment (nodejs/node#65035) <#65035 (comment)> Thanks for the detailed report and analysis. Guarding against reentrant OpenSSL calls or deferring callbacks both seem like reasonable approaches. Looking forward to seeing which solution the maintainers settle on. On Wed, Aug 5, 2026 at 10:16 AM wafir645fcqs4 ***@***.***> wrote: > *wafir645fcqs4* left a comment (nodejs/node#65035) > <#65035 (comment)> > Thanks for reporting this and for the detailed investigation. Deferring > or guarding these callbacks seems like a sensible approach to avoid unsafe > reentrant OpenSSL calls. Looking forward to the discussion on the best > implementation. > > On Wed, Aug 5, 2026 at 8:11 AM divVerent ***@***.***> wrote: > > > *divVerent* created an issue (nodejs/node#65035) > > <#65035> > > Version > > > > v26.5.0 > > Platform > > > > Darwin rpolzer-macbookpro.roam.internal 25.5.0 Darwin Kernel Version > 25.5.0: Tue Jun 9 22:18:58 PDT 2026; > root:xnu-12377.121.10~1/RELEASE_ARM64_T6000 arm64 > > > > Subsystem > > > > ssl_tls > > What steps will reproduce the bug? > > > > - Calling this._handle.destroySSL() from within the ALPNCallback > > - Calling client._handle.setServername('...') from within the > > on('keylog') callback > > - Calling this.write('...') from within the ALPNCallback > > > > How often does it reproduce? Is there a required condition? > > > > All of these reproduce every time. > > What is the expected behavior? Why is that the expected behavior? > > > > No segfault, no abort, no deadlock - just JS exceptions. > > What do you see instead? > > > > - Calling this._handle.destroySSL() from within the ALPNCallback > > causes segfault of NodeJS: > > > > * thread #1, name = 'node-MainThread', queue = 'com.apple.main-thread', > stop reason = breakpoint 1.1 > > * frame #0: 0x0000000188addaf4 libsystem_malloc.dylib`malloc_error_break > > frame #1: 0x0000000188ab19ac libsystem_malloc.dylib`malloc_vreport + 744 > > frame #2: 0x0000000188ab528c libsystem_malloc.dylib`malloc_report + 64 > > frame #3: 0x0000000188aba648 > libsystem_malloc.dylib`___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED > + 76 > > frame #4: 0x0000000100806e20 > libssl.3.dylib`tls_post_process_client_hello + 432 > > frame #5: 0x00000001007f6398 libssl.3.dylib`state_machine + 1424 > > frame #6: 0x00000001007e369c libssl.3.dylib`ssl3_read_bytes + 1788 > > frame #7: 0x00000001007982d4 libssl.3.dylib`ssl3_read_internal + 136 > > frame #8: 0x00000001007a34fc libssl.3.dylib`SSL_read + 28 > > frame #9: 0x0000000104b017cc > libnode.147.dylib`node::crypto::TLSWrap::ClearOut() + 324 > > frame #10: 0x0000000104b00c4c > libnode.147.dylib`node::crypto::TLSWrap::Cycle() + 52 > > frame #11: 0x0000000104b03558 > libnode.147.dylib`node::crypto::TLSWrap::OnStreamRead(long, uv_buf_t > const&) + 124 > > frame #12: 0x0000000104a7d40c > libnode.147.dylib`node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) + > 780 > > frame #13: 0x0000000104a7d810 > libnode.147.dylib`node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s*, > long, uv_buf_t const*) + 88 > > frame #14: 0x0000000100080660 libuv.1.dylib`uv__stream_io + 1000 > > frame #15: 0x00000001000851b0 libuv.1.dylib`uv__io_poll + 1252 > > frame #16: 0x0000000100076b64 libuv.1.dylib`uv_run + 276 > > frame #17: 0x0000000104904fd0 > libnode.147.dylib`node::SpinEventLoopInternal(node::Environment*) + 252 > > frame #18: 0x00000001049dbdd0 > libnode.147.dylib`node::NodeMainInstance::Run(node::ExitCode*, > node::Environment*) + 184 > > frame #19: 0x00000001049dbb04 > libnode.147.dylib`node::NodeMainInstance::Run() + 140 > > frame #20: 0x000000010497cfac libnode.147.dylib`node::Start(int, char**) > + 684 > > frame #21: 0x00000001888f3e00 dyld`start + 6992 > > > > > > - Calling client._handle.setServername('...') from within the > > on('keylog') callback causes assertion failure of NodeJS: > > > > # node[9656]: static void node::crypto::TLSWrap::SetServername(const > FunctionCallbackInfo<Value> &) at ../src/crypto/crypto_tls.cc:1381 > > # Assertion failed: !wrap->started_ > > > > > > - Calling this.write('...') from within the ALPNCallback causes > > deadlock (due to SSL_write within SSL_do_handshake). > > > > Additional information > > > > I can provide the exact .js files upon request. > > > > It would help if this._handle were not accessible but hidden within a > > closure, but it would not be sufficient (as you see, the deadlock one > > doesn't even need this). > > > > We plan to harden BoringSSL against issues like this by having reentrant > > or concurrent calls to SSL * functions (and maybe others) return a new > > ERR_R_BAD_CONCURRENCY which would safely prevent such issues; it would > > however force NodeJS to move to a different approach of providing these > > callbacks. In particular, NodeJS's own test suite assumes that you can > call > > write from onhandshakedone, which, albeit convenient, breaks invariants > > within both OpenSSL and BoringSSL and just "happens to work" for now, > but > > will be broken by the pending change. > > > > You can look at our pending patch for BoringSSL here: > > https://boringssl-review.googlesource.com/c/boringssl/+/97087 - this > > issue was actually found by testing this patch against known code bases. > > > > Possible solutions include: > > > > - Set a flag while in an OpenSSL callback, and have further SSL > > methods check that flag and throw immediately. > > - Defer callbacks to the next frame where possible (primarily, where > > the callback's return value is not needed). > > > > See also a related issue in CPython, found by the same audit: > > python/cpython#143756 <python/cpython#143756> > > > > — > > Reply to this email directly, view it on GitHub > > < > #65035?email_source=notifications&email_token=CKTGBQILOTXE3TAY2LG3PIT5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, > > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/CKTGBQJ4NBH7OIJOL5H3AI35ILFZFAVCNFSNUABEKJSXA33TNF2G64TZHMZDOMJZGM3TOOJ3JFZXG5LFHM2TANRXHEYTCMBVGCQXMAQ> > > > . > > Triage notifications, keep track of coding agent tasks and review pull > > requests on the go with GitHub Mobile for iOS > > < > https://github.com/notifications/mobile/ios/CKTGBQIBZI54TQ27AA74TIT5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> > > > and Android > > < > https://github.com/notifications/mobile/android/CKTGBQPX62RIEW64IO4O2WL5ILFZFA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJQGY3TSMJRGA2TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. > > > Download it today! > > You are receiving this because you are subscribed to this thread.Message > > ID: ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > < #65035?email_source=notifications&email_token=CKTGG2SXP56ZJQPKVJRBCUD5ILUPNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTENJSHE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5189325295>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/CKTGG2XDZ2IPGD4GXQBMTJ35ILUPNAVCNFSNUABEKJSXA33TNF2G64TZHMZDOMJZGM3TOOJ3JFZXG5LFHM2TANRXHEYTCMBVGCQXMAQ> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > < https://github.com/notifications/mobile/ios/CKTGG2UJA4GYB4UFJBX5FJL5ILUPNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTENJSHE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> > and Android > < https://github.com/notifications/mobile/android/CKTGG2VJT3T36GRAVW72FUD5ILUPNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTENJSHE22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. > Download it today! > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#65035?email_source=notifications&email_token=CKTJMVLSAA4U5KZ6FWP742L5ILVIPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTQNJUGQZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5189385443>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CKTJMVJBMMCV673R3ST6GS35ILVIPAVCNFSNUABEKJSXA33TNF2G64TZHMZDOMJZGM3TOOJ3JFZXG5LFHM2TANRXHEYTCMBVGCQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CKTJMVMKBMBWNIQANRXIM435ILVIPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTQNJUGQZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CKTJMVJ6232W3GSBX4Z4NT35ILVIPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJYHEZTQNJUGQZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[divVerent]

Also, from our perspective, the MVP would be deferring the onhandshakedone callback to next thread - this should get rid of the most common real-world reentrancy issue (SSL_do_handshake -> onhandshakedone -> SSL_write).

Once that is done, we should be safe to start enforcing this on BoringSSL end, and can then eliminate most potential crashes.

Sample code that e.g. will break if nothing is done:

node -e 'fetch("https://example.com");'

The reason being that undici invokes a callback from secureConnect:

node/deps/undici/undici.js

Line 3291 in 3e6cca0

cb(null, this);

which can basically do anything.

As that seems intentional, and doing socket work from a connect callback is generally fine, it probably is best to adjust how TLS sockets work and defer the callback to next frame.

[pimterry]

cc @nodejs/crypto

Thanks for the info @divVerent! Yes, we'll clearly need to handle this on our side.

It's difficult for us to drop _handle entirely for ecosystem compatibility reasons, but still it's absolutely not an official public API. Anybody calling methods on it directly is asking for trouble already, and taking correct handling of OpenSSL/BoringSSL into their own hands. Imo if that behaviour breaks there due to underlying lib changes, that's manageable. If serious issues in existing packages come up we can work around those if necessary, but we'd actively discourage anybody from doing this in the first place so I'm not too worried there.

The write case is different. That is a supported API which we should avoid breaking unexpectedly. It's very reasonable to write from secureConnect, and although its unusual to write from inside the other callbacks it is allowed, so none of that should stall or segfault. We should be buffering those writes (and any similar ops) automatically to make this work.

We plan to harden BoringSSL against issues like this by having reentrant or concurrent calls to SSL * functions (and maybe others) return a new ERR_R_BAD_CONCURRENCY which would safely prevent such issues

Judging from the patch, this is referring to SSL_read/write/peek, is that right? Just checking we're not disallowing things like SSL_get_servername etc during handshake, which we do need.

Also, from our perspective, the MVP would be deferring the onhandshakedone callback to next thread

There's a route here, but I think any significant changes to callback/event handling is more complicated and we end up with lots of tricky ordering games. I think we can easily emit current events as-is, but add better handling around our read & write APIs, to ensure they internally wait to manage this correctly.

In practice we effectively already do that in many cases, though inelegantly: right now it looks like we attempt the write and then just buffer & defer if it fails (here). This has some edge cases - I actually just fixed some of this a couple of days ago for TLS 1.2 resumption events, SNI & OCSP in #64827. Improving and hardening that flow should be easier and less user-visible than changing when the events themselves fire.

I'll look into it a bit today and fix that ALPN case now for starters, and see if there's a clean way to handle the whole class.

[divVerent]

Judging from the patch, this is referring to SSL_read/write/peek, is that right? Just checking we're not disallowing things like SSL_get_servername etc during handshake, which we do need.

For now; to be clear, any get function is definitely fine to call from a callback and will remain fine (although I would not recommend mutating any pointers returned, even if they happen to be non-const for historical compatibility reasons).

The biggest problems are with read/write ops; however various SSL_set_* functions also better not be called from a callback (unless the callback's documentation explicitly mentions to do so).

[davidben]

(There are a lot of config callbacks that call setters. That's mostly not a big deal. It's mostly driving the state machine that gets horrific when done re-entrantly.)

For context, the main the we want to trap in BoringSSL was concurrent use of the SSL object across threads, which isn't quite what's going on here. The issue there is it's sadly common for people to mistakenly call SSL_read on one thread and SSL_write on another thread, since that works with blocking sockets.

In an alternate universe, that would have been okay with libssl too. Some stacks do lock internally. Trouble is OpenSSL's API has so many thread-hostile patterns like getters that return non-owning pointers or how SSL_get_error inspects state that SSL_read left in a mailbox. That means there really isn't any locking we could do internally to support this API in a way that works with how these callers want. They have to drive it as a state machine around non blocking I/O and build blocking behavior out of it.

When we were trialing that out, we noticed the funny Node behavior, hence the bug. While in principle we could turn enforcement off around the callback, re-entrantly driving the state machine while the state machine is on the stack is... slightly horrifying. :-)

[pimterry]

I've opened a PR to guard the core read/write/shutdown cases in #65105.