FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

buffer: recreate pooled ArrayBuffer after transfer by lindsaycode05 · Pull Request #61364 · nodejs/node · GitHub

/ node Public

buffer: recreate pooled ArrayBuffer after transfer - #61364

Closed
lindsaycode05 wants to merge 1 commit into
nodejs:mainfrom
lindsaycode05:fix/buffer-transfer-pooled-ab
Closed

buffer: recreate pooled ArrayBuffer after transfer#61364
lindsaycode05 wants to merge 1 commit into
nodejs:mainfrom
lindsaycode05:fix/buffer-transfer-pooled-ab

Conversation

Copy link
Copy Markdown

Fixes #61362

Summary

  • After a Buffer backed by the internal pool has its ArrayBuffer detached (e.g. via ArrayBuffer.prototype.transfer()), subsequent Buffer.from(..., 'base64') calls would throw ERR_BUFFER_OUT_OF_BOUNDS. This change ensures pooled Buffer creation doesn’t rely on a detached pool ArrayBuffer.

Repro

const base64 = Buffer.from('hello', 'utf8').toString('base64');
const first = Buffer.from(base64, 'base64');
first.buffer.transfer();
Buffer.from(base64, 'base64'); // threw `ERR_BUFFER_OUT_OF_BOUNDS` before, succeeds now

Changes

  • Add a pool-detachment guard before pooled allocations.
  • Add a regression test for pooled base64 Buffer.from after transfer.

Tests

  • python3 tools/test.py test/parallel/test-buffer-pool-untransferable.js
  • make -j4 test

nodejs-github-bot added buffer Issues and PRs related to the buffer subsystem. needs-ci PRs that need a full CI run. labels Jan 13, 2026
const base64 = 'aGVsbG8='; // "hello"
const buf = Buffer.from(base64, 'base64');
buf.buffer.transfer();
assert.strictEqual(buf.buffer.byteLength, 0);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

The buffer should not be transferrable at all... This still transfers the underlying buffer.

ChALkeR commented Jan 13, 2026
edited
Loading

Copy link
Copy Markdown
Member

This just masks the issue.

const base64 = Buffer.from('hello', 'utf8').toString('base64');
const first = Buffer.from(base64, 'base64');
first.buffer.transfer();

this could have corrupted other buffers allocated prior to first, not just the ones allocated after that

> x = Buffer.from('hello')
<Buffer 68 65 6c 6c 6f>
> y = Buffer.from('world')
<Buffer 77 6f 72 6c 64>
> y.buffer.transfer()

> x
<Buffer >
> 

Which could also include buffers allocated by Node.js internally
Destroying operations on pooled Buffer .buffer are the problem here, not just the future buffer allocs

Copy link
Copy Markdown
Member

Thanks for the PR!

Ultimately, I think #61372 is the correct approach here. As Nikita mentioned, this doesn't really solve the underlying issue.

Copy link
Copy Markdown
Author

Thanks guys, that makes sense. Given the broader semantics (detaching a shared backing store invalidates all views), my PR isn’t the right, long-term fix. I’ll leave it to #61372 and maintainer direction from here. Appreciate the discussion and pointers! Feel free to close this PR whenever convenient.

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

Labels

buffer Issues and PRs related to the buffer subsystem. needs-ci PRs that need a full CI run.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Can not construct Buffer after different Buffer was previously transfererd

5 participants


Back | FazBrowse Home | New Git URL