Can not construct `Buffer` after different `Buffer` was previously transfererd

[lucacasonato]

Version

24.12.0

Platform

not relevant

Subsystem

lib/buffer

What steps will reproduce the bug?

> const buf = Buffer.from(btoa("hello"), "base64");
undefined
> buf.buffer.transfer();
ArrayBuffer {
  [Uint8Contents]: <2f 00 00 00 00 00 00 00 68 65 6c 6c 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 8092 more bytes>,
  [byteLength]: 8192
}
> 
> Buffer.from(btoa("hello"), "base64");
Uncaught RangeError: "offset" is outside of buffer bounds
    at Object.write (node:buffer:698:46)
    at fromStringFast (node:buffer:480:22)
    at fromString (node:buffer:504:51)
    at Buffer.from (node:buffer:310:12) {
  code: 'ERR_BUFFER_OUT_OF_BOUNDS'
}

This is the minimal reproduction. In reality this was encountered by two systems that were unaware of each other assuming the following:

• System 1 assumed that Buffer.from returns Uint8Array (subclasses) that after returning are owned by the caller
• System 2 assumed that any Uint8Array passed in is owned by it after passing it in

System 2 was detaching the ArrayBuffer because it passed it to the byobRequest.respond() method (which transfers the buffer). In practice this can and will happen more frequently going forward, because there is now a method to detach and transfer arbitrary ArrayBuffers: ArrayBuffer.prototype.transfer().

System 1 was unaware that transfers were going to happen.

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

The expected behaviour is that Buffer.from should return Uint8Array's that do not break when the underlying buffer of any one other returned Uint8Array is detached (ie, they should not use a pooled AB).

What do you see instead?

An error is thrown on unrelated Buffer.from() calls when the return value of a prior Buffer.from() is detached.

Additional information

A previous mitigation for this was attempted in #32759, but it is not effective anymore as ArrayBuffer.prototype.transfer() does not care about Node internal symbols on the ArrayBuffer pool.

[lindsaycode05]

I opened a PR with a fix + regression test: #61364; cc @lucacasonato.

I ran into the same failure path and traced it to pooled ArrayBuffer reuse after detachment/transfer, so the fix recreates the pool (or avoids pooled allocations when detached) to prevent subsequent Buffer.from() calls from causing that ERR_BUFFER_OUT_OF_BOUNDS, and added test coverage so it doesn't regress.

[lucacasonato]

Thanks! FWIW, there is a further bug where you create two Buffers, and then detach one. In that case they'll both be broken

[lindsaycode05]

Thanks for the note! The way I understand it is that if two Buffers share the same backing ArrayBuffer (as happens with the pool), detaching that ArrayBuffer invalidates all views into it, that’s expected by design because both views share the same backing store. It’s not a Node bug per se (it's expected JS behavior), but just a consequence of pooling + detachment.

Our fix here only ensures that subsequent Buffer.from() calls reinitialize the pool after a detach, so new buffers don’t fail. Existing pooled views will still be unusable once their backing store is detached, unless nodejs changes the pooling strategy.

[lucacasonato]

That's right - hence my suggestion to remove the pooling. Correctness > performance (in other words, performance improvements should not have detrimental observable side-effects).

[ChALkeR]

While I dislike Buffer pooling for security concerns (see linked discussion), this specific case seems like a non-issue

Buffers are behaving per ECMAScript spec, whatever is dealing with Buffer or Uint8Array instances can't assume that the view they receive is non-pooled or that there are no other views on the same underlying ArrayBuffer.

Any operation on .buffer (like what the issue does) on anything what is not a just-allocated Uint8Array is inherently unsafe and should be wrapped to properly clone input.

This and other mistakes operating directly on .buffer without checks affect not only pooled Buffer instances, but e.g. any result of u8arr.subarray() too.

---

Specifically:

System 2 assumed that any Uint8Array passed in is owned by it after passing it in

This is not correct regardless of Buffer being involved or not, unless the Uint8Array is allocated by System 2 itself.
It will fail not just on Buffer, but on subarrays, and will destroy data not belonging to it.

---

That said, #61372 seems to be reasonable