iemejia opened a new pull request, #3864: URL: https://github.com/apache/avro/pull/3864
## What is the purpose of the change A `bytes` or `string` value is encoded as a length prefix followed by that many bytes of data, and an `array` or `map` block is encoded as an element count followed by that many items. A malicious or truncated input can declare a very large length or count while carrying little or no actual data, which causes a correspondingly large allocation before the shortfall is noticed. This applies the equivalent of the Java SDK fix [AVRO-4241](https://issues.apache.org/jira/browse/AVRO-4241) to the Perl SDK: when the source can report how many bytes remain, a declared length (or a collection block count) that exceeds the bytes actually available is rejected before allocating for it. The collection check uses the minimum on-wire size of the element schema, so a zero-byte element type (such as `null`) is never falsely rejected. Sources that cannot report their remaining size are unaffected. `_bytes_remaining` reports the bytes still readable, found by seeking to the end and restoring the position; readers that cannot seek to the end (e.g. a streaming decompressor) yield undef and are simply skipped. `decode_bytes` rejects an over-large declared length above a threshold, and `decode_array`/`decode_map` reject a block whose element count could not be backed by the bytes remaining, using `_min_bytes_per_element` from the element schema. This is a sub-task of [AVRO-4292](https://issues.apache.org/jira/browse/AVRO-4292) and resolves [AVRO-4299](https://issues.apache.org/jira/browse/AVRO-4299). ## Verifying this change This change added tests and can be verified as follows: - Extended `lang/perl/t/03_bin_decode.t` with over-limit `bytes`/`array`/`map` rejection and an array of nulls that must not be falsely rejected. - Run: `cd lang/perl && prove -Ilib t/` ## Documentation - Does this pull request introduce a new feature? (no — hardening / robustness) - If yes, how is the feature documented? (not applicable) -- 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]
