iemejia commented on code in PR #3920:
URL: https://github.com/apache/avro/pull/3920#discussion_r3727542900
##########
lang/java/avro/src/main/java/org/apache/avro/reflect/ReflectDatumReader.java:
##########
@@ -143,6 +144,17 @@ protected Object readArray(Object old, Schema expected,
ResolvingDecoder in) thr
if (l <= 0) {
return newArray(old, 0, expected);
}
+ // Match GenericDatumReader.readArray: before eagerly allocating the
backing
+ // array for the declared block count, verify the input could plausibly
hold
+ // that many elements (guarding against a malformed or truncated payload),
+ // and separately cap element types whose minimum encoded size is zero,
which
+ // the bytes-remaining check cannot bound. Without this a small malformed
+ // record mapped to a Java array field (e.g. long[]) could drive a very
large
+ // eager allocation before any element is read.
+ ensureAvailableCollectionBytes(in, l, expectedType);
+ if (isZeroByteSchema(expectedType)) {
+ SystemLimitException.checkMaxCollectionAllocation(0, l);
+ }
Review Comment:
Good catch — fixed. I extracted a shared `nextArrayBlock` helper that
re-applies `ensureAvailableCollectionBytes` and, for zero-byte element schemas,
`checkMaxCollectionAllocation(existing, l)` after every `in.arrayNext()`, and
wired it into both `readObjectArray` and `readCollection` while tracking the
cumulative count. This mirrors `GenericDatumReader.readArray` so a large
logical array split across blocks is now bounded cumulatively. Added a
regression test
(`read_PojoWithZeroByteList_rejectsCumulativeCountAcrossBlocks`) covering two
blocks that individually pass but exceed the limit together. (fad19cd)
--
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]
