René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"fs: heap buffer overflow in readFileSync(fd, \"utf8\") when a pipe returns short reads","articleBody":"### Version\n\nv26.10.0 (also present in v26.8.0 through v26.10.0 and v24.21.0; not present in v26.7.0 or v22.23.3)\n\n### Platform\n\n```text\nLinux archpc 7.2.4-arch1-2 #1 SMP PREEMPT_DYNAMIC Tue, 08 Sep 2026 10:22:31 +0000 x86_64 GNU/Linux\nArch Linux, nodejs 26.10.0-1, glibc 2.44\n```\n\n### Subsystem\n\nfs\n\n### What steps will reproduce the bug?\n\n```bash\n#!/usr/bin/env bash\n# Producer: 24 short writes (~96 KiB, each read back as a short read), then one large write.\nnode -e '\nconst chunk = \"x\".repeat(4000);\nlet i = 0;\nconst t = setInterval(() => {\n  process.stdout.write(chunk);\n  if (++i === 24) { clearInterval(t); process.stdout.write(\"y\".repeat(400000)); }\n}, 5);\n' | node -e 'console.log(require(\"fs\").readFileSync(0, \"utf8\").length)'\necho \"exit=${PIPESTATUS[1]}\"\n```\n\n### How often does it reproduce? Is there a required condition?\n\n10 of 10 runs with the script above. The input must be a pipe (or FIFO, or `/dev/stdin` backed by one) that delivers more than 64 KiB in reads shorter than 8 KiB before the first full 8 KiB read. Regular files are not affected. The encoding does not matter: the input above is pure ASCII.\n\nReal-world trigger: `some-test-runner | node -e 'require(\"fs\").readFileSync(0, \"utf8\")...'`, where the producer writes in small chunks. It crashed at 7 of 60 runs with a ~420 KB input written in 4093-byte chunks.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nPrints `496000` and exits 0, as v26.7.0 does and as `readFileSync(0).toString(\"utf8\")` does on v26.10.0.\n\n### What do you see instead?\n\n```text\nmalloc(): invalid size (unsorted)\nexit=134\n```\n\nSIGABRT from glibc. Symbolized stack (from a real crash, via debuginfod.archlinux.org):\n\n```text\n#6  malloc_printerr (str=\"malloc(): invalid size (unsorted)\") at malloc.c:5093\n#7  _int_malloc (av=\u003cmain_arena>, bytes=427486) at malloc.c:3683\n#10 __GI___libc_realloc (oldmem=0x0, bytes=427486) at malloc.c:3198\n#11 node::UncheckedRealloc\u003cchar16_t> (pointer=0x0, n=\u003coptimized out>) at ../../src/util-inl.h:267\n#13 node::MaybeStackBuffer\u003cunsigned short, 256ul>::AllocateSufficientStorage (storage=213743) at ../../src/util-inl.h:544\n#14 node::StringBytes::Encode (...) at ../../src/string_bytes.cc:659\n#15 node::fs::ReadFileUtf8 (args=...) at ../../src/node_file.cc:3559\n```\n\nThe abort happens later than the corruption. The corruption itself is a heap buffer overflow in `ReadFileUtf8`.\n\n### Additional information\n\nCause, in `ReadFileUtf8` ([src/node_file.cc#L3511-L3523 at v26.10.0](https://github.com/nodejs/node/blob/59da6b44a953cf9b45f2591ae80f569ce1ec9da5/src/node_file.cc#L3511-L3523)):\n\n- While `big == nullptr`, every short read (`r \u003c 8192`) is appended to `result` and the loop `continue`s. On a pipe, `result` can grow past 64 KiB this way.\n- On the first full 8 KiB read, the code allocates `big_cap = kMinChunk` (64 KiB) and runs `memcpy(big, result.data(), result.size())` with no check that `result.size() \u003c= big_cap`. That write overflows the heap buffer.\n- After that, `big_len > big_cap`, so `big_len == big_cap` never matches, and `big_cap - big_len` in the next `uv_buf_init` underflows.\n\nA possible fix: size the first allocation from what is already buffered, for example `big_cap = std::max(kMinChunk, result.size() + sizeof(buffer))`, and make the growth check `big_len >= big_cap`.\n\nWorkaround: `fs.readFileSync(0).toString(\"utf8\")` avoids the fast path.\n","author":{"url":"https://github.com/bartech-lab","@type":"Person","name":"bartech-lab"},"datePublished":"2026-09-27T08:15:04Z","url":"https://github.com/nodejs/node/issues/66341"}