andygrove opened a new pull request, #1422:
URL: https://github.com/apache/arrow-java/pull/1422
## What's Changed
`ArrowFieldNode` previously accepted a negative `length`. Because the IPC
(`MessageSerializer.deserializeRecordBatch`), JSON (`JsonFileReader`), and C
Data
(`ArrayImporter`) deserialization paths construct `ArrowFieldNode` directly
from
externally supplied metadata, a malformed or hostile input could set a
negative node
length that then flowed into buffer-size math and buffer writes:
- `BitVectorHelper.getValidityBufferSizeFromCount` uses an unsigned shift,
so a small
negative length becomes a ~512 MB allocation request.
- `BitVectorHelper.loadValidityBuffer` then calls `ArrowBuf.setOne(0, length
/ 8)` with a
negative byte count. With bounds checking disabled
(`arrow.enable_unsafe_memory_access=true`) this reaches `Unsafe.setMemory`
with the
negative value reinterpreted as a huge unsigned length (memory
corruption); with bounds
checking enabled it throws only after a large buffer has been allocated
and the vector's
previous validity buffer already released.
This PR validates `length >= 0` once, in the `ArrowFieldNode` constructor,
which is the
single chokepoint shared by every deserialization path and every vector
type. A negative
length now fails fast with a clear `IllegalArgumentException` before any
buffer is sized or
written. `nullCount` is intentionally left unvalidated because
`VectorUnloader` uses `-1`
as a sentinel meaning "null count not included".
Added `TestArrowFieldNode` covering rejection of a small negative length,
rejection of a
large negative length (caught before the narrowing cast), acceptance of zero
and positive
lengths, and preservation of the `nullCount == -1` sentinel.
Closes #1421.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
