Nayana-Naik73 opened a new pull request, #51755:
URL: https://github.com/apache/arrow/pull/51755
### Rationale for this change
Reading through the optimised varlen cast macros in
gdv_string_function_stubs.cc I noticed the date64 one looks under-sized.
GDV_FN_CAST_VARLEN_TYPE_FROM_DATE64 reserves an arena buffer of `min(len, 10)`
bytes with the comment "Output is always YYYY-MM-DD = 10 chars max", and the
shared formatter suffix then copies `min(len, size)` bytes from
StringFormatter<Date64Type> into it. That ten-byte assumption does not hold:
the formatter widens to "-YYYYY-MM-DD" (up to 12 bytes) for years outside four
digits, and for a millisecond value past its supported year range it returns
"<value out of range: <int64>>" (up to 42 bytes). date64 values are just int64
milliseconds, so with a cast length above 10 the copy runs past the ten-byte
slot and corrupts the following arena allocation. It is reachable from CAST(d
AS VARCHAR) / CAST(d AS VARBINARY) over untrusted date64 column data.
I confirmed it by replaying the macro's allocation and copy under ASan for
the value 9000000000000000 ms with length 100: a 38-byte memcpy ("<value out of
range: 9000000000000000>") into the 10-byte region. The sibling integer macro
(digits10 + 2) and float macro (24, which is the double-conversion shortest
maximum, I checked the formatter never exceeds it) are both sized correctly, so
only the date64 path needs changing.
### What changes are included in this PR?
Raise max_date_str_len from 10 to 42, the longest rendering the formatter
can produce ("<value out of range: " is 21 bytes, plus up to 20 int64 digits,
plus ">"). The `min(len, max)` behaviour is otherwise unchanged, so a smaller
requested length still truncates as before. This covers both helpers the macro
generates, VARCHAR and VARBINARY.
### Are these changes tested?
Yes. Added TestGdvFnStubs.TestCastVARCHARFromMillisecondsOutOfRange, which
casts an out-of-range date64 and then does a second cast into the same arena
chunk; with the old ten-byte reservation the second allocation overlaps and
corrupts the first result, so the test fails before this change and passes
after. The existing date64 cast tests still pass.
### Are there any user-facing changes?
No. Only casts that previously overflowed are affected.
**This PR contains a "Critical Fix".** It fixes a heap buffer overflow
reachable from casting an untrusted date64 column to VARCHAR/VARBINARY in
Gandiva.
### Was AI used for this PR?
**PR code and description written by:**
- [ ] Human
- [x] AI
**Reviewed before submission by:**
- [x] Human
- [ ] AI
- [ ] Not reviewed
--
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]
