Zoltán Borók-Nagy created IMPALA-15227:
------------------------------------------
Summary:
TimestampValue::UtcFromUnixTimeMicros/UtcFromUnixTimeLimitedRangeNanos throw on
out-of-range input instead of returning an invalid value
Key: IMPALA-15227
URL: https://issues.apache.org/jira/browse/IMPALA-15227
Project: IMPALA
Issue Type: Bug
Reporter: Zoltán Borók-Nagy
UtcFromUnixTimeTicks<T> computes a day count and constructs EPOCH +
boost::gregorian::date_duration(days). When days pushes the year outside boost
gregorian's valid [1400, 9999] range, boost throws std::out_of_range ("Year is
out of valid range: 1400..9999") rather than yielding a not_a_date_time /
invalid TimestampValue.
Callers assume the conversion always returns and rely on a subsequent validity
check (e.g. FormatDefault(...) <= 0) to reject bad values. That check is
unreachable for extreme inputs. Affected untrusted-input paths:
- parquet-common.h Int64ToTimestampValue (MICRO/NANO) — reachable from any
corrupt/crafted Parquet file with an out-of-range INT64 timestamp.
- VARIANT decoding (variant-value.cc, TIMESTAMPNTZ / TIMESTAMPNTZ_NANOS) —
added in IMPALA-15221; the "value out of range" Status guard is dead code for
extreme inputs.
- Potentially the Kudu scanner path (kudu-scanner.cc:413).
An uncaught exception here risks crashing the impalad rather than returning SQL
NULL / a graceful error.
*Repro*:
TimestampValue::UtcFromUnixTimeMicros(std::numeric_limits<int64_t>::max())
throws
*Suggested fix*: range-check the day count inside UtcFromUnixTimeTicks (or the
UtcFromUnixTime* wrappers) and return a default/invalid TimestampValue() when
out of the representable range, so existing validity checks work as intended
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
