[Arawoof06]

Rationale for this change

castVARCHAR/castVARBINARY from date64 size their output block with a hard-coded 10 (YYYY-MM-DD), but the copy that follows is bounded by the caller-supplied length rather than by what was allocated. arrow::internal::StringFormatter<Date64Type> goes past 10 bytes in two ways: years outside 0-9999 need 11-12, and values it cannot represent go through detail::FormatOutOfRange, which emits up to 42 bytes.

So castVARCHAR(<date64>, 64) on an out-of-range value writes 42 bytes into a 10-byte arena block and sets out_len to 42, corrupting whatever the execution context hands out next.

The float macro has the same shape, a 24-byte constant against a formatter documented to use a 50-byte buffer, so it carries the same mismatch even though current Java-style output happens to stay under 24.

What changes are included in this PR?

The arena allocation moves inside the formatter callback, where the real formatted size is known, so the allocation and the copy use one bound. That drops the guessed constant from both the date64 and float macros.

Are these changes tested?

Yes. TestCastVARCHARFromMillisecondsLongOutput casts an out-of-range date64 and then allocates again from the same context. On the unpatched tree it reads back:

<value out12345a12345-9223372036854775808>

It passes after the change, and needs no sanitizer to fail. gandiva-internals-test, gandiva-precompiled-test and gandiva-projector-test all pass locally.

Are there any user-facing changes?

Dates and out-of-range values that format to more than 10 bytes now return the full string, truncated to the requested length, instead of writing past the block. Dates that already fit are unaffected.

This PR contains a "Critical Fix". Heap buffer overflow reachable from SQL castVARCHAR on a date64 value.

---

Disclosure of AI usage, per the AI-generated code guidance: this was produced with AI assistance, using BugQore's multi-agent redemption system. That covered locating the mismatch, writing the patch, and writing the regression test. Verified before opening: the new test fails on the unpatched tree with the corrupted output shown above and passes after, the three Gandiva suites are green, and clang-format 18.1.8 (the version pinned in .pre-commit-config.yaml) reports no changes. Happy to walk through any part of the reasoning in review.

• GitHub Issue: [C++][Gandiva] Heap buffer overflow casting date64 to VARCHAR #50539

[github-actions]

⚠️ GitHub issue #50539 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #50539 has no components, please add labels for components.

[Arawoof06]

gentle ping

[dmitry-chirkov-dremio]

@Nayana-Naik73 @Arawoof06 could you two review each other's proposals (#50540 vs #51755) pick an approach?

My preference is 50540's exact sizing.

[Arawoof06]

I went through #51755. Its 42-byte bound is right for StringFormatter<Date64Type> as it stands (21 for the prefix, up to 20 digits, 1 for the closing >), so both PRs close the overflow. The difference is that #51755 still keeps a hand-picked constant that has to track the formatter's output. Here the block is allocated inside the callback from the actual formatted size, so allocation and copy can't drift apart. The float macro gets the same treatment, and a normal date only allocates the 10 bytes it writes.

Going with the exact sizing here, as you suggested. @Nayana-Naik73, your 9000000000000000 case is already covered by the out-of-range path in TestCastVARCHARFromMillisecondsLongOutput, so nothing from #51755 should get lost.

[Nayana-Naik73]

Went through this as asked. Moving the allocation into the callback looks right to me: the block is sized from min(len, size) so the allocation and the copy can't drift apart, the len == 0 return in the prefix still happens before the formatter is ever called, and the nullptr check after the callback covers a formatter that returns without invoking it. I also checked the test values against formatting.h: 253402300800000 ms is 10000-01-01, which FormatYYYY_MM_DD prints as 11 bytes, and int64 min falls outside IsDateTimeInRange so it goes through FormatOutOfRange and comes out at 42 bytes, which matches the bound I had in #51755.

One small thing, not blocking: an arena_malloc failure inside the callback now surfaces as "Could not cast ... to string" rather than "Could not allocate memory", since the OutOfMemory status gets folded into the generic error. Fine with closing #51755 in favour of this once it lands.

[Arawoof06]

@Nayana-Naik73 fair point on the OOM path. It used to report "Could not allocate memory" before the formatter ran, and now that status gets folded into the generic cast error. Since it's non-blocking and this is approved, I'll leave it as is here. If @dmitry-chirkov-dremio would rather keep the distinct message, it's a small change to set it inside the callback and skip the generic one.