René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"http2: assertion failure `onread->IsFunction()` when a session is destroyed from a 'stream' handler","articleBody":"## What steps will reproduce the bug?\n\n`node:http2` aborts on an internal assertion when an HTTP/2 session is destroyed from inside a `'stream'` handler while the peer's DATA frames are still in the receive buffer:\n\n```\nnode[...]: v8::MaybeLocal\u003cv8::Value> node::StreamBase::CallJSOnreadMethod(ssize_t, v8::Local\u003cv8::ArrayBuffer>, std::size_t, StreamBaseJSChecks) at ../src/stream_base.cc:473\nAssertion failed: onread->IsFunction()\n\n 1: node::Assert(node::AssertionInfo const&)\n 2: node::StreamBase::CallJSOnreadMethod(...)\n 3: node::http2::Http2StreamListener::OnStreamRead(long, uv_buf_t const&)\n 4: node::http2::Http2Session::OnDataChunkReceived(nghttp2_session*, unsigned char, int, unsigned char const*, unsigned long, void*)\n 5: nghttp2_session_mem_recv2\n 6: node::http2::Http2Session::ConsumeHTTP2Data()\n 7: node::http2::Http2Session::OnStreamRead(long, uv_buf_t const&)\n```\n\n`handle.onread` is assigned in exactly one place — `Http2Stream[kInit]` in `lib/internal/http2/core.js` — so nghttp2 is delivering a DATA chunk to a stream whose JS wrapper has already been torn down.\n\nThis is reachable from ordinary peer behaviour: the server simply destroys its own session from the `'stream'` handler, which runs inside `ConsumeHTTP2Data()`.\n\n## Minimal reproduction\n\nNo dependencies, no TLS. Aborts within a few hundred rounds, typically well under the 5s default window:\n\n```js\n'use strict'\n\n// Standalone reproduction — node:http2 only, no dependencies.\n//\n// An HTTP/2 server destroys its own session from inside the 'stream' handler,\n// which nghttp2 dispatches from within Http2Session::ConsumeHTTP2Data. The\n// client sends several concurrent POSTs whose HEADERS and DATA arrive in the\n// same receive buffer, so nghttp2 keeps delivering DATA for the remaining\n// streams after JS has torn the session down. Delivery then reaches a stream\n// whose JS wrapper is gone:\n//\n//   node::StreamBase::CallJSOnreadMethod at ../src/stream_base.cc:473\n//   Assertion failed: onread->IsFunction()\n//     \u003c- node::http2::Http2StreamListener::OnStreamRead\n//     \u003c- node::http2::Http2Session::OnDataChunkReceived\n//     \u003c- nghttp2_session_mem_recv2\n//     \u003c- node::http2::Http2Session::ConsumeHTTP2Data\n//\n// handle.onread is assigned in exactly one place, Http2Stream[kInit]\n// (lib/internal/http2/core.js), so the C++ side is calling into a stream that\n// was destroyed while the receive operation was still in flight.\n//\n// Usage:\n//   node repro-h2-abort.js\n//\n// Exit status 134 (SIGABRT) means it reproduced; 0 means it survived the run.\n// Reproduces over cleartext h2 (and equally over TLS), and does not depend on\n// --expose-gc.\n\nconst http2 = require('node:http2')\n\nconst DURATION = Number(process.env.DURATION || 5000)\nconst STREAMS = Number(process.env.STREAMS || 8)\n// Small enough that HEADERS and DATA coalesce into a single read.\nconst BODY = Buffer.alloc(Number(process.env.BODY || 2048), 'a')\n\nconst serverOptions = {\n  settings: { maxConcurrentStreams: Number(process.env.MAX_CONCURRENT_STREAMS || 4) }\n}\n\nconst server = http2.createServer(serverOptions)\n\nserver.on('session', (session) => session.on('error', () => {}))\n\n// The whole trigger: tear the connection down from inside the stream handler,\n// i.e. while nghttp2 is still walking the buffer that delivered this stream.\nserver.on('stream', (stream) => {\n  stream.on('error', () => {})\n  stream.session.destroy()\n})\n\nlet rounds = 0\n\nserver.listen(0, '127.0.0.1', () => {\n  const port = server.address().port\n  const origin = `http://127.0.0.1:${port}`\n  let stopped = false\n\n  const round = () => {\n    if (stopped) return\n    rounds++\n\n    const session = http2.connect(origin)\n    session.on('error', () => {})\n    session.on('close', () => setImmediate(round))\n\n    session.on('connect', () => {\n      for (let i = 0; i \u003c STREAMS; i++) {\n        const stream = session.request({ ':path': `/${i}`, ':method': 'POST' })\n        stream.on('error', () => {})\n        stream.resume()\n        stream.end(BODY)\n      }\n    })\n  }\n\n  round()\n\n  setTimeout(() => {\n    stopped = true\n    console.log(`survived ${rounds} rounds without aborting`)\n    server.close()\n    process.exit(0)\n  }, DURATION)\n})\n\n```\n\n```console\n$ node repro-h2-abort.js\nAssertion failed: onread->IsFunction()\nAborted (core dumped)\n$ echo $?\n134\n```\n\nDoes not depend on `--expose-gc` (4/4 with and without). Reproduces over TLS as well; the `TLSWrap::ClearOut` frame in the original stack was incidental.\n\n## Affected versions\n\n| build | result (3 runs each) |\n|---|---|\n| `main` @ `012ecf51d39`, clean checkout | **3/3 abort** |\n| v24.18.0 (release binary) | 0/3 — ~6,000 rounds clean |\n| v22.22.3 (release binary) | 0/3 — ~6,000 rounds clean |\n\n## Bisect\n\nIntroduced by **46de80de88c6ab0fc1fa27aa4d51804c7e989da4** — *http2: avoid uaf while receiving and sending rst_stream* (#64166, fixing #64113):\n\n```\n46de80de88c    BAD  (rc=134)\n46de80de88c~1  GOOD\n```\n\nThat commit defers session close while `nghttp2_session_mem_recv()` is in progress:\n\n```cpp\nif (is_receiving()) {\n  set_close_pending();\n  pending_close_code_ = code;\n  pending_close_socket_closed_ = socket_closed;\n  return;   // finished later via MaybeFinishPendingClose()\n}\n```\n\nOur reproduction destroys the session from inside a `'stream'` handler, i.e. *while receiving*. Before that change the close completed immediately and the torn-down streams stopped receiving data. With the close deferred, nghttp2 keeps walking the same receive buffer and delivers DATA to streams whose JS wrappers have already been destroyed, so `CallJSOnreadMethod` finds `onread` unset.\n\nSo the fix for one use-after-free in the `mem_recv` window appears to have opened a different lifetime hole in the same window. Note this is *not* addressed by `ba6cb5c34c2` (*http2: defer rst stream while in scope*) — I cherry-picked that on top and it still aborts 5/5.\n\n## Discovery\n\nFound via `undici`'s HTTP/2 test suite, where it surfaced under `borp` as a bare `'test failed'` with one subtest silently missing and no assertion text — worth knowing, since that signature is easy to mistake for flakiness. Running the test file directly is what exposes exit 134.\n\ncc @Eusgor @mcollina @pimterry @RafaelGSS\n","author":{"url":"https://github.com/mcollina","@type":"Person","name":"mcollina"},"datePublished":"2026-07-30T19:55:21Z","url":"https://github.com/nodejs/node/issues/64850"}