[
https://issues.apache.org/jira/browse/AVRO-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismaël Mejía reassigned AVRO-4275:
----------------------------------
Assignee: Ismaël Mejía
> [C] Signed integer overflow in read_array_value / read_map_value negation of
> block_count
> ----------------------------------------------------------------------------------------
>
> Key: AVRO-4275
> URL: https://issues.apache.org/jira/browse/AVRO-4275
> Project: Apache Avro
> Issue Type: Bug
> Components: c
> Reporter: Ismaël Mejía
> Assignee: Ismaël Mejía
> Priority: Critical
> Labels: security
> Fix For: 1.13.0
>
>
> The C SDK binary value decoder in {{lang/c/src/value-read.c}} negates an
> attacker-controlled {{int64_t block_count}} unconditionally when the count is
> negative:
> {code:c}
> // read_array_value(), line 56:
> block_count = block_count * -1;
> // read_map_value(), line 92:
> block_count = block_count * -1;
> {code}
> Per the Avro spec, a negative block count means the absolute value of the
> count, followed by a block byte-size prefix. However, when {{block_count ==
> INT64_MIN}} (zigzag bytes {{FF FF FF FF FF FF FF FF FF 01}}), the negation is
> signed-integer overflow — undefined behavior in C (CWE-190). On x86_64 / gcc
> -O0 the result wraps back to {{INT64_MIN}}. The subsequent loop:
> {code:c}
> for (i = 0; i < (size_t) block_count; i++, index++) {
> avro_value_append(dest, &child, NULL);
> ...
> }
> {code}
> casts the still-negative value to {{(size_t)0x8000000000000000}} (~9.2
> quintillion iterations), driving {{avro_raw_array_ensure_size}} doubling
> reallocs until address-space exhaustion.
> *Impact:* A single ~11-byte malformed Avro binary frame can wedge a decoding
> thread and exhaust process memory (DoS). This is the C SDK counterpart to the
> Java SDK pattern fixed in 1.11.3 via
> {{SystemLimitException.checkMaxCollectionLength}} (CVE-2023-39410).
> *Affected versions:* All releases of the C SDK up to and including 1.12.0.
> *Fix:* Replace the unsafe {{block_count * -1}} with the overflow-safe idiom
> {{-(block_count + 1) + 1}} (same approach used in the C++ fix AVRO-4228),
> followed by a guard that rejects the result if it remains non-positive:
> {code:c}
> block_count = -(block_count + 1) + 1;
> if (block_count <= 0) {
> avro_set_error("Invalid array block count");
> return EINVAL;
> }
> {code}
> This eliminates the undefined behavior, rejects {{INT64_MIN}} gracefully, and
> preserves correct handling of all legitimate negative block counts.
> *Reported by:* Brian Lee (Georgia Tech SSLab)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
