arib06 opened a new pull request, #3904: URL: https://github.com/apache/avro/pull/3904
## What is the purpose of the change `avro_resolver_union_branch` (the `avro_consume_binary` / `avro_resolver_new` consumer path) read the writer union branch number from the datum and used it directly to index `child_resolvers`, with no bounds check. `read_union` in `consume-binary.c` decodes the discriminant as an `int64_t` and passes it to a callback typed `unsigned int`, so a negative or large value becomes a huge index; `avro_resolver_union_branch` then read `child_resolvers[discriminant]` past the array and, when that slot was non-NULL, handed the garbage pointer back as an `avro_consumer_t *` that `avro_consume_binary` dispatched through. On a two-branch union fed discriminant 100 (bytes `C8 01`), ASAN reports a heap-buffer-overflow READ of size 8 at `resolver.c:1119`. The value decoder already rejects out-of-range discriminants; this older consumer path was missed. The check belongs here because this is the single place that indexes the resolver array with the wire value (the `avro_schema_union_branch` chokepoint used elsewhere already returns NULL on a miss). ## Verifying this change This change added tests and can be verified as follows: - Added `test_avro_resolver_union_bounds`, which builds a resolver for a `["null","string"]` union and feeds `avro_consume_binary` a datum whose discriminant (100) exceeds the branch count, asserting the read fails instead of crashing. Without the fix the test triggers a heap out-of-bounds read (confirmed under AddressSanitizer); with it the call returns `EILSEQ`. The full `ctest` suite passes. ## Documentation - Does this pull request introduce a new feature? no -- 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]
