Arawoof06 opened a new pull request, #50540: URL: https://github.com/apache/arrow/pull/50540
### 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](https://arrow.apache.org/docs/dev/developers/overview.html#ai-generated-code): 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
