[
https://issues.apache.org/jira/browse/AVRO-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismaël Mejía resolved AVRO-4276.
--------------------------------
Resolution: Duplicate
Superseded by AVRO-4294. The INT64_MIN block-count negation fix for [C++] has
been folded into that issue's PR (https://github.com/apache/avro/pull/3859)
together with the broader collection allocation bounding, forming a single
complete fix for the C++ SDK. Resolving as a duplicate/superseded; the
standalone PR here is closed in favour of #3859.
> [C++] BinaryDecoder::doDecodeItemCount() should reject INT64_MIN block count
> ----------------------------------------------------------------------------
>
> Key: AVRO-4276
> URL: https://issues.apache.org/jira/browse/AVRO-4276
> 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
> Time Spent: 50m
> Remaining Estimate: 0h
>
> BinaryDecoder::doDecodeItemCount() in lang/c++/impl/BinaryDecoder.cc does not
> reject INT64_MIN as a block count. While the -(result + 1) + 1 idiom (added
> in AVRO-4228) correctly avoids undefined behavior during negation, it
> converts INT64_MIN to 2^63 as the item count. Callers such as Generic.cc then
> attempt vector::resize(2^63), which will throw std::bad_alloc since no system
> can allocate that much memory.
> The zigzag encoding of INT64_MIN is a valid 10-byte varint (FF FF FF FF FF FF
> FF FF FF 01), so the decoder can encounter this value when reading malformed
> or corrupted data. Rather than propagating an impossibly large count that
> inevitably fails downstream, the decoder should reject it early with a clear
> error.
> The C binding already rejects INT64_MIN explicitly (AVRO-4275). The C++
> binding should do the same for consistency and robustness.
> Fix: Guard against INT64_MIN before negation in doDecodeItemCount(), and
> simplify the negation to -result (safe once INT64_MIN is excluded).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
