fix: parseBuffer misreads Buffers that are offset views into a larger ArrayBuffer#424
fix: parseBuffer misreads Buffers that are offset views into a larger ArrayBuffer#424KristianBicba wants to merge 1 commit into
Conversation
modesty
left a comment
There was a problem hiding this comment.
Buffer.from(buf.buffer, buf.byteOffset, buf.byteLength) produces a view identical to the input (same backing store, same offset) — it's effectively a no-op. The data is now read correctly at the top level, but the downstream Stream_makeSubStream(start, length, dict) applied to the raw backing ArrayBuffer — so every sub-stream (XRef streams, object streams, content streams) reads from the wrong position. Problem persists.
The correct fix must copy into a fresh, zero-offset backing store, to make it fit with what's required by makeSubStream: function Stream_makeSubStream.
a test that feeds an offset view (Buffer.from(new ArrayBuffer(n + 1024), 1024, n) with bytes set) of one classic-xref and one xref-stream fixture through parseBuffer is needed
parseBuffer normalizes buffers whose backing ArrayBuffer is larger than the view, but it rebuilds the view from offset 0 instead of the buffer's actual byteOffset. The parser then reads unrelated bytes from the backing store and fails on valid PDFs, typically with Invalid XRef stream header.
This started biting in practice on Node.js ≥ 24.18.0, where Buffer.from(str, 'base64') returns a view into a shared 64 KB pool (byteOffset > 0) for decoded payloads under ~64 KB. Any PDF that arrives base64-encoded (a very common case for API payloads) now fails to parse, on all pdf2json versions through 4.0.3.