[
https://issues.apache.org/jira/browse/AVRO-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismaël Mejía updated AVRO-4275:
-------------------------------
Description:
The C SDK binary value decoder in {{lang/c/src/value-read.c}} negates
{{block_count}} unconditionally when the value 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 indicates that the absolute value is
the item count, followed by a block byte-size prefix. However, certain negative
values cannot be safely negated in {{int64_t}} -- the multiplication is
signed-integer overflow (undefined behavior in C, CWE-190). On common platforms
the result remains negative; the subsequent cast to {{size_t}} in the loop
condition then yields an extremely large iteration count, driving unbounded
memory allocation until process exhaustion.
This is the C SDK counterpart to the Java SDK issue fixed in 1.11.3 via
{{SystemLimitException.checkMaxCollectionLength}} (CVE-2023-39410). The C++ SDK
equivalent was fixed in AVRO-4228.
*Affected versions:* All releases of the C SDK up to and including 1.12.0.
*Fix:* Replace the unsafe multiplication-based negation with the overflow-safe
idiom used in the C++ fix (AVRO-4228), followed by a validity guard that
rejects non-positive results:
{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 invalid input gracefully, and
preserves correct handling of all legitimate negative block counts.
*Reported by:* Brian Lee (Georgia Tech SSLab)
was:
The C SDK binary value decoder in {{lang/c/src/value-read.c}} negates
{{block_count}} unconditionally when the value 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 indicates that the absolute value is
the item count, followed by a block byte-size prefix. However, certain negative
values cannot be safely negated in {{int64_t}} — the multiplication is
signed-integer overflow (undefined behavior in C, CWE-190). On common platforms
the result remains negative; the subsequent cast to {{size_t}} in the loop
condition then yields an extremely large iteration count, driving unbounded
memory allocation until process exhaustion.
This is the C SDK counterpart to the Java SDK issue fixed in 1.11.3 via
{{SystemLimitException.checkMaxCollectionLength}} (CVE-2023-39410). The C++ SDK
equivalent was fixed in AVRO-4228.
*Affected versions:* All releases of the C SDK up to and including 1.12.0.
*Fix:* Replace the unsafe multiplication-based negation with the overflow-safe
idiom used in the C++ fix (AVRO-4228), followed by a validity guard that
rejects non-positive results:
{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 invalid input gracefully, and
preserves correct handling of all legitimate negative block counts.
*Reported by:* Brian Lee (Georgia Tech SSLab)
> [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.12.2
>
>
> The C SDK binary value decoder in {{lang/c/src/value-read.c}} negates
> {{block_count}} unconditionally when the value 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 indicates that the absolute value
> is the item count, followed by a block byte-size prefix. However, certain
> negative values cannot be safely negated in {{int64_t}} -- the multiplication
> is signed-integer overflow (undefined behavior in C, CWE-190). On common
> platforms the result remains negative; the subsequent cast to {{size_t}} in
> the loop condition then yields an extremely large iteration count, driving
> unbounded memory allocation until process exhaustion.
> This is the C SDK counterpart to the Java SDK issue fixed in 1.11.3 via
> {{SystemLimitException.checkMaxCollectionLength}} (CVE-2023-39410). The C++
> SDK equivalent was fixed in AVRO-4228.
> *Affected versions:* All releases of the C SDK up to and including 1.12.0.
> *Fix:* Replace the unsafe multiplication-based negation with the
> overflow-safe idiom used in the C++ fix (AVRO-4228), followed by a validity
> guard that rejects non-positive results:
> {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 invalid input 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)
