Nayana-Naik73 opened a new issue, #51754:
URL: https://github.com/apache/arrow/issues/51754
### Describe the bug, including details regarding any error messages,
version, and platform.
The `castVARCHAR`/`castVARBINARY` helpers for date64 in
`cpp/src/gandiva/gdv_string_function_stubs.cc` (generated by the
`GDV_FN_CAST_VARLEN_TYPE_FROM_DATE64` macro) allocate an arena buffer of
`min(len, 10)` bytes, assuming `StringFormatter<Date64Type>` always emits a
10-byte `YYYY-MM-DD` string. The shared `GDV_FN_CAST_VARLEN_FORMATTER_SUFFIX`
then copies `min(len, size)` formatter bytes into that buffer.
That 10-byte assumption does not hold. `StringFormatter<Date64Type>` widens
to `-YYYYY-MM-DD` (up to 12 bytes) for years outside four digits, and for a
millisecond value beyond its supported year range it emits `<value out of
range: <int64>>` (up to 42 bytes). date64 values are plain int64 milliseconds,
so any of these is representable in a column. When the cast length is above 10
the copy runs past the 10-byte allocation, a heap buffer overflow into adjacent
arena memory. It is reachable from `CAST(d AS VARCHAR)` / `CAST(d AS
VARBINARY)` over untrusted date64 column data.
Minimal reproduction of the allocation + copy path under ASan (value
9000000000000000 ms is out of range, length 100):
```
WRITE of size 38 at ... thread T0
#0 __asan_memcpy
0x... is located 0 bytes after 10-byte region [...]
formatter output (38 bytes): <value out of range: 9000000000000000>
```
The sibling integer macro (`digits10 + 2`) and float macro (24, the
double-conversion shortest maximum) are correctly sized; only the date64 macro
under-sizes.
### Component(s)
C++, Gandiva
--
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]
