buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB#62500
Open
crawfordxx wants to merge 1 commit intonodejs:mainfrom
Open
buffer: fix 32-bit truncation in SlowCopy for buffers larger than 4 GiB#62500crawfordxx wants to merge 1 commit intonodejs:mainfrom
crawfordxx wants to merge 1 commit intonodejs:mainfrom
Conversation
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 nodejs#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: nodejs#55422
nodejs-github-bot
added
buffer
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SlowCopyinsrc/node_buffer.ccextractedtargetStart,sourceStart,and
to_copyvia.As<Uint32>()->Value(), silently truncating values thatexceed
2^32 - 1(4 GiB). This causedBuffer.prototype.copy()to copythe 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 (usingsize_t) withUint32Value(32-bit).Changes
src/node_buffer.cc: UseIntegerValue()(returnsint64_t) inSlowCopyinstead of
.As<Uint32>()->Value(), and widenCopyImpl's parameter typesfrom
uint32_ttosize_t.FastCopyis left unchanged — V8's Fast API guarantees it is only invokedwhen all arguments fit in
uint32_t; for larger values V8 falls back toSlowCopyautomatically.test/parallel/test-buffer-copy-large.js: New test that allocates a bufferslightly larger than 4 GiB and verifies
Buffer.prototype.copy()copies allbytes correctly. The test skips gracefully on systems with insufficient memory.
Test
Fixes #55422