[ 
https://issues.apache.org/jira/browse/AVRO-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095532#comment-18095532
 ] 

ASF subversion and git services commented on AVRO-4275:
-------------------------------------------------------

Commit 35b0bddda5b5fedea20f515fe315c2721a2d022b in avro's branch 
refs/heads/avro-cpp-issue from Ismaël Mejía
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=35b0bddda5 ]

AVRO-4275: [C] Strengthen test assertions to check EINVAL

Assert that the INT64_MIN block count tests fail with the specific
EINVAL error code rather than just any non-zero return. This ensures
the tests actually exercise the new guard rather than passing due to
an unrelated failure downstream.

Addresses review feedback on PR #3842.

Assisted-by: GitHub Copilot:claude-opus-4.6


> [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
>    Affects Versions: 1.11.5, 1.12.1
>            Reporter: Ismaël Mejía
>            Assignee: Ismaël Mejía
>            Priority: Critical
>              Labels: pull-request-available
>             Fix For: 1.12.2
>
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> 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}}. 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)

Reply via email to