buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB by crawfordxx · Pull Request #62500 · nodejs/node · GitHub

Summary

SlowCopy in src/node_buffer.cc extracted targetStart, sourceStart,
and to_copy via .As<Uint32>()->Value(), silently truncating values that
exceed 2^32 - 1 (4 GiB). This caused Buffer.prototype.copy() to copy
the wrong number of bytes or write to the wrong position when dealing with
buffers larger than 4 GiB.

Root cause was introduced in #54087 ("buffer: use native copy impl"), which
replaced the original ParseArrayIndex-based extraction (using size_t) with
Uint32Value (32-bit).

Changes

src/node_buffer.cc: Use IntegerValue() (returns int64_t) in SlowCopy
instead of .As<Uint32>()->Value(), and widen CopyImpl's parameter types
from uint32_t to size_t.
FastCopy is left unchanged — V8's Fast API guarantees it is only invoked
when all arguments fit in uint32_t; for larger values V8 falls back to
SlowCopy automatically.
test/parallel/test-buffer-copy-large.js: New test that allocates a buffer
slightly larger than 4 GiB and verifies Buffer.prototype.copy() copies all
bytes correctly. The test skips gracefully on systems with insufficient memory.

Test

// Before fix: only 5 bytes were copied (2^32 + 5 mod 2^32 = 5).
// After fix: all FOUR_GB + 5 bytes are copied correctly.
const src = Buffer.alloc(2 ** 32 + 5, 0xbb);
const dst = Buffer.alloc(src.length, 0xaa);
src.copy(dst);
assert.strictEqual(dst[dst.length - 1], 0xbb);

Fixes #55422

Don't use checked operations here.

Suggested change

      
              const size_t target_start =
          
                  static_cast<size_t>(args[2]->IntegerValue(ctx).ToChecked());
          
              const size_t source_start =
          
                  static_cast<size_t>(args[3]->IntegerValue(ctx).ToChecked());
          
              const size_t to_copy =
          
                  static_cast<size_t>(args[4]->IntegerValue(ctx).ToChecked());
          
              CopyImpl(source_obj, target_obj, target_start, source_start, to_copy);
          
              int64_t target_start, source_start, to_copy; 
          
              if (!args[2]->IntegerValue(env->context()).To(&target_start) || 
          
                  !args[3]->IntegerValue(env->context()).To(&source_start) || 
          
                  !args[4]->IntegerValue(env->context()).To(&to_copy)) { 
          
                return; 
          
              } 
          
              CopyImpl(source_obj, 
          
                       target_obj, 
          
                       static_cast<size_t>(target_start), 
          
                       static_cast<size_t>(source_start), 
          
                       static_cast<size_t>(to_copy));

Please also change the FastCopy argument and return types from uint32_t to uint64_t.

Copying gigabytes of buffer memory is a massive operation. Can this just test copying a small chunk of memory with source/target offsets of >2^32?

SlowCopy extracted targetStart, sourceStart, and to_copy using `.As<Uint32>()->Value()`, which silently truncates values that exceed 2^32-1 (4 GiB). As a consequence, Buffer.prototype.copy() produced incorrect results when operating on buffers larger than 4 GiB: only the lower 32 bits of each offset/count were used, causing writes to the wrong location or copying far fewer bytes than requested. Fix by extracting those arguments with `IntegerValue()` (which yields int64_t) and casting to size_t, matching the behaviour of the previous `ParseArrayIndex`-based implementation that existed before PR #54087. CopyImpl's parameter types are widened to size_t accordingly. FastCopy retains uint32_t parameters because V8's Fast API contract guarantees it is only invoked when all arguments fit in uint32_t; for larger values V8 falls back to SlowCopy automatically. Add test/parallel/test-buffer-copy-large.js to cover the regression. The test allocates a buffer slightly larger than 4 GiB and verifies that Buffer.prototype.copy() copies all bytes correctly; it skips gracefully on systems with insufficient memory. Fixes: #55422

Addressed all three review comments:

Checked operations — switched to non-checked .To() pattern with int64_t and env->context() (added Environment* env = Environment::GetCurrent(args) at the top of SlowCopy).
FastCopy types — argument types and return type changed from uint32_t to uint64_t.
Test memory — replaced the 2×4GiB allocation with a single ~4GiB src buffer. Writes 10 sentinel bytes at offset FOUR_GB, then copies only those 10 bytes to a tiny 10-byte dst using src.copy(dst, 0, FOUR_GB, FOUR_GB + 10). If source_start were truncated to uint32 (→ 0) the test would read 0xaa bytes from the start of the buffer instead of the 1..10 sentinels, catching the regression with far less memory pressure.

nodejs-github-bot added buffer Issues and PRs related to the buffer subsystem. c++ Issues and PRs that require attention from people who are familiar with C++. needs-ci PRs that need a full CI run. labels Mar 30, 2026

Renegade334 reviewed Mar 30, 2026

View reviewed changes

crawfordxx closed this Mar 31, 2026

crawfordxx requested a review from a team as a code owner March 31, 2026 04:12

rafaelmfried mentioned this pull request May 18, 2026

buffer: add regression test for copy beyond 2 GiB #62942

Closed

+              // Copy the entire large buffer.  The native _copy binding receives
+              // to_copy = FOUR_GB + 5.  Before the fix, Uint32 truncation reduced this to
+              // 5, leaving all but the first 5 bytes of dst unchanged (still 0xaa).
+              src.copy(dst);

buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB by crawfordxx · Pull Request #62500 · nodejs/node · GitHub

Uh oh!

Uh oh!

buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB - #62500

buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB#62500
crawfordxx wants to merge 1 commit into
nodejs:mainfrom
crawfordxx:fix-buffer-copy-overflow-for-large-buffers

crawfordxx commented Mar 30, 2026

Uh oh!

Renegade334 Mar 30, 2026 •
edited
Loading

Uh oh!

Uh oh!

Renegade334 Mar 30, 2026

Uh oh!

Renegade334 Mar 30, 2026 •
edited
Loading

Uh oh!

Uh oh!

crawfordxx commented Mar 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB by crawfordxx · Pull Request #62500 · nodejs/node · GitHub

Uh oh!

Uh oh!

buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB - #62500

buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB#62500crawfordxx wants to merge 1 commit intonodejs:mainnodejs/node:mainfrom crawfordxx:fix-buffer-copy-overflow-for-large-buffersCopy head branch name to clipboard

Conversation

crawfordxx commented Mar 30, 2026

Summary

Changes

Test

Uh oh!

Renegade334 Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Renegade334 Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

Renegade334 Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

crawfordxx commented Mar 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB#62500
crawfordxx wants to merge 1 commit into
nodejs:mainfrom
crawfordxx:fix-buffer-copy-overflow-for-large-buffers

Renegade334 Mar 30, 2026 •
edited
Loading

Renegade334 Mar 30, 2026 •
edited
Loading