[woolfi182]

The stateless reset tokens that a QUIC session generates for its own connection IDs (Session::GenerateNewConnectionId() for NEW_CONNECTION_ID frames, and TransportParams::GeneratePreferredAddressToken()) were registered in SessionManager::token_map_. That map is what Endpoint::Receive() consults to recognize a stateless reset sent by the peer; per the comments in endpoint.cc and session_manager.h, it should only contain tokens previously given by the remote peer, and sessions clean up their entries on teardown.

Teardown (Session::Impl::~Impl()) only removes the peer's tokens (ngtcp2_conn_get_active_dcid2()), so the locally issued entries were never removed and kept a raw Session* after the session was destroyed. A short header packet for an unknown connection ID ending in one of those tokens was then:

• dispatched to the destroyed session and silently dropped, instead of being answered with a stateless reset, and
• once the Session had been garbage collected, a use-after-free in maybeStatelessReset().

This change stops registering locally issued tokens. They are still generated and sent to the peer; nothing on the receive side needs them, since the peer's tokens are registered through the dcid_status callback.

The new test reads the server's NEW_CONNECTION_ID tokens from its qlog, destroys the session, and sends the server endpoint a short header packet that ends in one of those tokens, followed by a control packet. Each reply is matched to its packet by the reset token derived from the packet's destination connection ID. Without the fix, the server answers only the control packet, and the process often crashes with SIGSEGV (an ASAN build reports a heap-use-after-free in Session::is_destroyed()); with it, both packets get a stateless reset.

QUIC is at Stability 1.0 behind --experimental-quic, so per SECURITY.md this is handled as a regular bug.

AI disclosure: this change was developed with assistance from Claude Code (analysis, fix and test). I reviewed the change and verified locally that the new test fails without the fix and passes with it, and that parallel/test-quic-* and the QUIC cctests pass.

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.