Copilot commented on code in PR #3862:
URL: https://github.com/apache/avro/pull/3862#discussion_r3567394511
##########
lang/ruby/lib/avro/io.rb:
##########
@@ -481,11 +546,14 @@ def skip_union(writers_schema, decoder)
end
def skip_array(writers_schema, decoder)
- skip_blocks(decoder) { skip_data(writers_schema.items, decoder) }
+ min_bytes = min_bytes_per_element(writers_schema.items)
+ skip_blocks(decoder, min_bytes) { skip_data(writers_schema.items,
decoder) }
Review Comment:
While the skip-path hardening is being expanded here (via `skip_blocks`
bounds), `skip_union` still reads the union branch index and uses it directly
to index `writers_schema.schemas`. In Ruby, negative indices are valid and can
silently select the wrong branch during projection/skipping. Please add the
same bounds check used by `read_union` and raise `AvroError` when the index is
negative or >= branch count.
##########
lang/ruby/lib/avro/io.rb:
##########
@@ -64,8 +75,14 @@ def read_long
b = byte!
n = b & 0x7F
shift = 7
+ # An Avro long is a 64-bit zig-zag varint, at most 10 bytes. Bound the
+ # continuation chain so a malicious input cannot force unbounded
Integer
+ # growth (and heavy CPU/memory use) before any caller-side check runs.
+ count = 1
while (b & 0x80) != 0
+ raise AvroError, "Varint is too long" if count >= 10
b = byte!
+ count += 1
n |= (b & 0x7F) << shift
shift += 7
end
Review Comment:
`read_long` now enforces the 10-byte max for Avro long encodings, but
`BinaryDecoder#skip_long` still loops until it finds a byte without the
continuation bit. If a long field is being *skipped* (e.g., during projection),
a malicious payload can still supply an arbitrarily long continuation chain and
force the decoder to scan large amounts of input (CPU/time DoS) instead of
failing fast. Consider applying the same 10-byte bound (and raising
`AvroError`) in `skip_long` as well.
--
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]
