You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Zoltán Borók-Nagy (Jira)" <ji...@apache.org> on 2026/09/18 08:52:00 UTC

[jira] [Resolved] (IMPALA-15221) Harden VARIANT decoding against corrupt/malicious offsets

     [ https://issues.apache.org/jira/browse/IMPALA-15221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Zoltán Borók-Nagy resolved IMPALA-15221.
----------------------------------------
    Fix Version/s: Impala 5.0.0
       Resolution: Fixed

> Harden VARIANT decoding against corrupt/malicious offsets
> ---------------------------------------------------------
>
>                 Key: IMPALA-15221
>                 URL: https://issues.apache.org/jira/browse/IMPALA-15221
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Backend
>            Reporter: Zoltán Borók-Nagy
>            Assignee: Zoltán Borók-Nagy
>            Priority: Major
>              Labels: impala-iceberg, impala-iceberg-active-backlog
>             Fix For: Impala 5.0.0
>
>
>   The variant decoder in be/src/runtime/variant-value.cc performs almost no bounds checking on offsets and lengths read from the value/metadata blobs. Since VARIANT is an external interchange type written by other engines (Spark, Flink, Trino, DuckDB) into Iceberg/Parquet files, these blobs are untrusted input. A corrupt or adversarial
>   blob can cause reads outside the allocated buffer — a crash or information disclosure (unrelated heap memory streamed into query results via JSON conversion), not just an incorrect result.
>   Unchecked paths include:
>   - VariantMetadata::Init() — offset values are never validated to point within the string-data region, and (dict_size_ + 1) * offset_size_ is computed as int, so a large dict_size_ overflows and defeats the length guard.
>   - GetString/GetBinary — string/binary length is taken directly from the blob with no check against the buffer length.
>   - GetFieldByIndex/GetArrayElement — element offsets are unchecked and next_offset - field_offset can unsigned-underflow.
>   - Object/array field counts drive raw pointer arithmetic with no bound.
>   - The only existing guards are DCHECKs, which are compiled out in release builds.
>   This was surfaced in review of IMPALA-15052 (gerrit 24521), which makes the decoder reachable from client-facing query output.
>   Fix:
>   - Metadata: validate the offset table once in Init() (monotonic, last offset ≤ string-data length) and fix the integer overflow.
>   - Value data: add per-access bounds guards (string/binary length, element offsets, field counts) and convert ReadValue's DCHECK to a real check.
>   Testing: add a negative-test matrix in variant-util-test.cc covering truncated metadata, out-of-range/non-monotonic offsets, overflowing dict_size, oversized string/binary lengths, underflowing element lengths, and out-of-range field ids.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)